Skip to content

2026

  • 9 min read

MASWE v1.0.0 is Here

We just released MASWE v1.0.0, the first stable release of the Mobile Application Security Weakness Enumeration. Two years after we introduced the beta, every weakness is now fully written, consistently structured and stably numbered.

This one was a genuine team effort. The OWASP MAS Task Force pulled the whole catalogue apart, argued about scope, merged what was redundant, wrote what was missing, and put it back together. This post explains what came out of that, what changed since the beta, and why it matters for the work still ahead in MASTG v2.

Where We Came From

When we announced MASWE in July 2024, the goal was to fill the gap between high-level MASVS controls and low-level MASTG tests. A MASVS control like "The app employs current strong cryptography and uses it according to industry best practices" is abstract by design. A MASTG test is specific to one platform, one API, one observable outcome. MASWE is the layer in between: the platform-agnostic weakness that explains why the listed tests exist.

The MASTG v2.0.0 released in June 2026 shipped with every test linked to a specific MASWE weakness, and the full traceability chain became real:

MASVS control → MASWE weakness → MASTG test → MASTG demo.

But the beta catalogue itself was not finished. It had 119 entries, and 89 of them were still placeholders: a title, some metadata, and draft content with notes to ourselves about what the page should eventually say.

There was also drift: the 30 entries that were fully written had been authored over two years by different people with different instincts, and the result was inconsistent in both structure and scope. Some put Impact before Modes of Introduction. Some wrote Impact as a paragraph, others as a list. Some described consequences under Modes of Introduction, and testable causes under Impact. Some were narrowly scoped to a single API, others spanned half a MASVS category. Several described the same underlying issue from different angles.

That is acceptable for a beta version, but not for something the industry expects to reference by ID.

What MASWE v1.0.0 Is

78 weaknesses, every one fully written:

Category Count ID range
MASVS-STORAGE 6 MASWE-0001–0006
MASVS-CRYPTO 11 MASWE-0007–0017
MASVS-AUTH 8 MASWE-0018–0025
MASVS-NETWORK 3 MASWE-0026–0028
MASVS-PLATFORM 12 MASWE-0029–0040
MASVS-CODE 10 MASWE-0041–0050
MASVS-RESILIENCE 15 MASWE-0051–0065
MASVS-PRIVACY 13 MASWE-0066–0078

What Changed Since the Beta

1. Consolidation, from 119 to 78

The beta had grown organically, and it showed. Nine separate entries described "unsafe handling of data from X" for nine different values of X. Ten more described missing authentication on ten different kinds of app components. Written out in full, each of those families would have produced a stack of near-identical pages saying the same thing in slightly different words — and would have pushed that duplication straight down into the tests.

To overcome this: 72 weaknesses were renamed and rescoped, 47 were merged into others, and 6 brand-new ones were created. Some of the larger consolidations include:

The six brand-new weaknesses fill gaps the beta simply did not have:

2. Stable, meaningful IDs

IDs are now consecutive and grouped by category, MASWE-0001 through MASWE-0078 with no gaps, in the MASVS canonical order STORAGE → CRYPTO → AUTH → NETWORK → PLATFORM → CODE → RESILIENCE → PRIVACY. Within a category, weaknesses are ordered by their first MASVS control, so all MASVS-STORAGE-1 weaknesses precede the MASVS-STORAGE-2 ones.

This means the renumbering was a one-time event, done deliberately before v1.0.0. From here on, IDs are stable. New weaknesses get the next free number and will not necessarily be consecutive within their category, but no existing ID will ever move or be recycled, only deprecated and removed if needed.

We want to be mindful of the people and organizations that are already using the MASWE beta, so we are providing a one-time mapping from the beta to the v1.0.0 IDs. This mapping is only available with the v1.0.0 release and is provided in machine-readable format. The beta mappings will be temporarily included in each MASWE metadata, but they will be removed in an upcoming release.

3. A fixed anatomy for every weakness

Every page now follows the same four sections, in the same order, with the same rules:

  1. Overview — opens with a single-sentence definition in the form "This weakness occurs when …", then 2–5 short paragraphs of plain prose. No code, no test procedures, no mitigations.
  2. Modes of Introduction — only developer-introduced, testable causes. What someone did, or failed to do, that put the weakness in the app.
  3. Impact — only consequences.
  4. Mitigations — imperative, actionable instructions addressed to a developer.

Each bullet in Modes of Introduction and Mitigations starts with a bold short label, which makes them addressable in review and, as we will see, maps cleanly onto MASTG content.

The discipline that took the most effort was keeping causes and consequences apart. A bullet like "Hardcoded Keys: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation" has a cause and a consequence welded together. In v1, the cause stays in Modes of Introduction and the consequence moves to Impact, where it belongs. It sounds pedantic, but it is the difference between a section you can turn into tests and a section you cannot.

We also enforced platform-agnosticism, with a deliberate exception for clarity. It is fine to mention the Android KeyStore and the iOS Keychain as examples of platform-provided key storage, or SharedPreferences and UserDefaults as examples of general-purpose key-value storage that offers no protection beyond the app sandbox. Those are the clearest way to make the point. It is not fine to name WebView and WKWebView separately when "WebView" says the same thing. Any mobile platform specifics belong in the MASTG.

4. A canonical vocabulary for impact

The Impact section in MASWE v1.0.0 became a focused list of consequences — each opening with a label from a fixed vocabulary of ten, and each closing with a resulting in clause:

Compromise of Sensitive Data · Authentication or Authorization Bypass · Bypass of Protection Mechanisms · Execution of Unauthorized Code · Financial Loss · Compromise of System Integrity and Business Operations · Violation of User Privacy · Loss of User Trust · Legal and Regulatory Non-Compliance · Compromise of Content or UI Integrity

Equivalent consequences now use identical wording across all 78 weaknesses.

5. A requirement for every weakness

Every weakness now carries a single normative sentence stating the positive requirement the app must fulfil — the inverse of the weakness:

This gives every weakness a directly usable requirement statement for policies, contracts, and scorecards, without anyone having to negotiate the phrasing themselves.

6. Deeper, audited mappings

We also added mappings to help further understand the weaknesses beyond MASWE, including:

  • All 24 MASVS v2 controls
    • were re-verified for all 78 weaknesses against the actual control definitions, not just carried over from the rename.
    • are covered by at least one weakness.
  • All 44 risks documented on Android's Security & Privacy risks page
    • were reviewed against Android's risk documentation.
    • map to at least one weakness.
  • Every item in the "Privacy and security" section of the Android Core App Quality checklist
    • were linked to 25 Android-relevant weaknesses using the new named IDs (Network_Security_Traffic, Minimize_Permissions, Cryptographic_Algorithms, …)
    • map to at least one weakness.
  • 93 distinct CWEs are referenced, keeping MASWE anchored to the broader software security ecosystem.

Why This Matters

Mobile app security requirements are increasingly written into regulation and certification, not just into pentest reports. The MASVS and MASTG are already referenced by Google's MASA program via the App Defense Alliance, by CREST OVS, by NIST SP 800-163r1 and SP 800-218, by BSI TR-03161 for eHealth apps, by the ioXt Alliance, and by government bodies like Singapore or India. When a standard is cited in a certification scheme, ambiguity in that standard becomes ambiguity in someone's compliance obligation.

A weakness enumeration is the layer where that ambiguity gets resolved, because it is the level people actually cite. "The app failed MASVS-STORAGE-2" is not a finding anyone can act on. "The app failed MASWE-0005, mode of introduction: verbose logging in production" is.

The Roadmap Hiding in Plain Sight

Here is the part we find most interesting: the MASWE authoring standard says a MASWE is not a test, not a demo, not a platform deep-dive, and not a countermeasure recipe. Those live in the MASTG. But the structure we settled on means each weakness now tells us exactly which of those are missing:

Every Mode of Introduction should have a test: A mode of introduction is, by construction, a developer-introduced condition that is testable — that rule was enforced across all 78 pages. So each one is a MASTG-TEST candidate, usually one per platform.

Every Mitigation should have a best practice: A mitigation is, by construction, an actionable instruction to a developer. That is precisely what a MASTG-BEST is.

36 of the 78 weaknesses have no MASTG test at all yet. Among them:

... and most of MASVS-PRIVACY.

That is not a complaint about MASTG v2. It is the first time we have been able to state the remaining work as a finite, enumerated list instead of a feeling that there is more to do.

If you have ever wanted to contribute to the MAS project but did not know where to start: pick a weakness with no tests, pick one of its modes of introduction, and write the test that detects it. The MASWE page already tells you what the test has to prove.

Thank You

This release came from a single pull request containing 186 files. It was created by consolidating all previous cross-industry feedback and reviews from the OWASP MAS Task Force team. The PR was open for two weeks and received 500 inline review comments (yes, this puts GitHub PRs to their limits. We generally do not recommend working on such large PRs, but in our situation, it was necessary). We don't want to use that number to impress anyone, but it really speaks to the quality of the release. Nearly every comment was a specific, researched objection to a particular sentence, and the catalog has much improved because of them.

Thank you to everyone in the OWASP MAS Task Force who worked through it, in alphabetical order:

Special thanks to Carlos Holguera (@cpholguera) for driving the remapping, the consolidation, and the authoring standard that made a catalogue of this size internally consistent.

We also want to thank everyone in the wider community who filed issues, opened discussions, or told us at a conference that a particular weakness did not make sense or could be improved. A lot of the merges in this release started as someone pointing out that two pages were saying the same thing.

And we cannot thank our MAS Advocates enough for their continuous contributions:

  • NowSecure
  • Guardsquare
  • vulnit

Feedback Wanted

MASWE v1.0.0 is live:

If you have used the beta MASWE IDs, you can consult the mappings to v1.0.0 from here: https://github.com/OWASP/maswe/releases/download/v1.0.0/OWASP_MASWE.yaml

And if you want to contribute, come and talk to us or jump straight into the GitHub discussions. There has never been a clearer map of what is left to build.

  • 4 min read

OWASP MAScon Vienna Recap - First Edition

In June 2026 we hosted the very first MAScon as part of OWASP Global AppSec EU 2026 at the Austria Center Vienna. It was a milestone year for OWASP, celebrating its 25th anniversary, and a milestone week for the Mobile Application Security (MAS) project hosting its very own conference.

A Full Room, From Start to Finish

MAScon brought together mobile security researchers, penetration testers, developers and AppSec leaders for a full day dedicated to mobile application security. The room stayed packed throughout the event, with great engagement during the sessions, Q&A and the hallway discussions that kept going long after the talks ended.


Photo Credit: Adriana Castro

The program covered offensive research, runtime internals, dynamic instrumentation and real-world mobile security incidents:

  • Let's get frooky: Structured Mobile DAST with Frida by Carlos Holguera & Stefan Bernhardsgrütter A session on the practical challenges of mobile penetration testing and how structured, Frida-powered instrumentation can help assess hardened applications at runtime.
  • Unveiling the Internals from Multiplatform Mobile Runtimes by Sergi Alvarez ("pancake") A deep dive into the internals of the main multiplatform frameworks (Flutter, React Native, Unity) — covering their languages, ecosystems and toolchains, and how to recover code and data from binaries using radare2 plugins.
  • Recent Mobile App Security Incidents from Real-World Cases by Jan Seredynski A walk-through of concrete incidents from banking, food delivery and e-commerce apps, breaking down how the breaches happened and which security practices hold up (or fail) in modern mobile apps.
  • Meet the New Frida Frontend on the Block by Ole André Vadla Ravnås The creator of Frida presents the new Frida frontend, the next evolution of the dynamic instrumentation tooling the mobile security community relies on.
  • Attacking ART by Jeroen Beckers A lesser-known technique targeting the Android Runtime (ART) through ODEX and VDEX manipulation — advanced instrumentation particularly relevant for resiliency assessments and apps protected by strong resiliency controls.

The OWASP MAS team (Carlos Holguera and Sven Schleier) held the opening and closing session for the first edition.


Photo Credit: Adriana Castro

What made the day special was seeing the community built around the MASVS, MASTG and MASWE come together in person. The people who build the standards, methodologies and tools used across the industry and practitioners using it in their daily work.

A big thank you to all speakers, attendees, volunteers, the OWASP events team (Starr Brown, Stacey Ebbs and Lauren Thomas) and our sponsors for making the first MAScon a success.

Read the recap from our MAS Advocate NowSecure here.

Next Stop: Berlin 🇩🇪

The momentum continues! The next MAScon will take place on October 7–9, 2026 at CityCube Berlin, as part of next.app devcon, alongside droidcon, fluttercon and other mobile developer conferences — a great opportunity to bring mobile security directly to thousands of mobile developers and engineering leads.


Photo Credit: Adriana Castro

The Call for Speakers is open: If you have practical mobile security content to share, whether it's secure coding, testing techniques, reverse engineering or applying the OWASP MAS standards, we'd love to hear from you.

👉 Submit your talk or get your ticket

See you in Berlin!

  • 5 min read

vulnit Achieves MAS Advocate Status

We are very happy to announce that vulnit has officially been granted the MAS Advocate status, the highest recognition possible within the OWASP Mobile Application Security (MAS) project.

This status isn't handed out lightly. It's reserved for organizations that have demonstrated consistent, high-impact contributions over a sustained period, dedicating not just technical resources but genuine commitment and passion to the OWASP MAS project — going beyond occasional contributions, as outlined in our official guidelines. The path to MAS Advocate demands at least six months of proven, impactful support, and in reality often much longer depending on the scope and depth of contributions.

Who is vulnit?

vulnit is a mobile security consultancy specializing in iOS and Android application security assessments, reverse engineering, and security research. Their team's hands-on expertise in runtime analysis, obfuscation, and anti-tampering mechanisms made them a natural fit for some of the most technically complex parts of the MASTG.

Their two primary contributors to the OWASP MAS project are @jacobocasado (Jacobo Casado de Gracia) and @sgIOlas (Sergio García Cabrera), both mobile security specialists who not just ported tests into the MASTG v2, but brought genuine technical depth to every interaction.

vulnit's Focus: MASVS-RESILIENCE

From their very first pull request, vulnit targeted the MASVS-RESILIENCE category, which covers the anti-analysis defenses built into hardened mobile applications to detect or resist tampering, debugging, reverse engineering, and execution in non-genuine environments. The v1 MASTG chapters on these topics were some of the most complex in the guide: mixing bypass strategies, effectiveness assessments, and platform-specific detection mechanisms into long prose chapters. So, porting these to v2's atomic format with a single, precise check per test required genuine understanding of the subject matter.

Across 9 v1 test ports, vulnit produced 17 new atomic v2 tests and 16 runnable demos — each with verified device output, working Frida scripts, or r2 analysis commands across topics like anti-debugging detection, emulator detection, obfuscation, dynamic instrumentation tools detection, app permissions, sensitive data in text fields and more.

Reviews That Went Beyond Comments

What set vulnit apart was not only the volume of their advocacy work, but the depth and judgment behind it. They did not approach the MASTG migration as a mechanical porting exercise. Their reviews questioned whether each item still represented a real security risk, whether it should remain a test, and whether the content would be more useful as a knowledge article or technique instead. This critical review mindset led them to challenge assumptions, validate behavior, and push concrete improvements directly into the content.

Their reviews were not limited to approvals, comments, or minor suggestions. In several cases, their review work became hands-on co-development, improving the structure, technical accuracy, metadata, and practical usefulness of the final tests.

Some examples include:

  • PR #3809: reviewing the MASTG-TEST-0057 port (Sensitive Data in Text Input Fields), @jacobocasado identified that the original test conflated two different analysis approaches into one. He restructured it into a proper static+dynamic pair: the static test uses r2 to look for isSecureTextEntry API references in the binary, while the dynamic test hooks resignFirstResponder at runtime via Frida to capture which text fields expose sensitive content at the moment of input. He verified the Frida script output on a real jailbroken device running Frida 17.9.7, added the expected output, and wrote the corrected Observation and Evaluation sections.
  • PR #3827: after reviewing the iOS hook detection test, @jacobocasado submitted a full rewrite: converting the test from a static check to a dynamic one, aligning it with its Android counterpart, adding concrete iOS API examples (fishhook, substrate), and documenting expected false negatives for cases where hook detection is implemented in native code that may not be visible at the Java/Kotlin layer.
  • PR #3871: @sgIOlas reviewed the File Integrity Checks port, checking the consistency of the Observation and Evaluation sections and validating the technique cross-references.
  • PR #3883: in collaboration with Guardsquare, after their implicit intents port (#3807), @jacobocasado reviewed the content thoroughly and submitted a follow-up to improve the technical accuracy of the test description, tightening the Evaluation section language and adding missing edge cases for intent broadcast scenarios.
  • PRs #3846 and #3862: in collaboration with NowSecure, they co-authored the iOS App Permissions port (#3563) and the IPC Sensitive Functionality port (#3842), both highly detailed and covering both the technical accuracy of the test content and the correctness of the metadata (weakness, profiles, best-practices links).

This pattern shows deep collaboration in practice. vulnit did not simply review completed work from the sidelines, and they did not treat migration as a one to one conversion of old material into the new structure. They worked with other contributors, verified technical claims, questioned whether the content still belonged as a test, and helped decide when a topic should instead become a technique or knowledge article.

That level of judgment is what made their reviews and self-authored PRs especially valuable. They improved not only the wording of individual tests, but also the quality of the model behind them. This is exactly the kind of contribution the MAS Advocate criteria calls for, reviews grounded in thorough analysis, constructive feedback, and actionable improvements that demonstrate clear ownership of the topic.

Active Participation in the MAS Task Force

Throughout their evaluation period, both @jacobocasado and @sgIOlas participated consistently in the monthly MAS Task Force calls, presenting their work, flagging questions about test design, and proactively following up on issues raised in previous sessions. They always came prepared and contributed to shaping decisions regarding MASTG v2 and OWASP MAS standards in general.

A Win for Mobile App Security

With NowSecure, Guardsquare, and now vulnit as MAS Advocates, the MASVS-RESILIENCE category — long one of the least-well-documented areas of mobile security testing — now has dedicated expert coverage. The tests vulnit produced and refined will help practitioners, tool authors, and assessment teams work with a rigorous, unambiguous reference rather than the loosely structured narrative they had before.

vulnit: "We are proud to contribute to the OWASP MASTG. Having been involved in the world of security certification, we know how important it is to have a reference standard that is available to everyone and developed by passionate people who are always open to suggestions for improvement. Thank you to Carlos, Sven, and the teams at NowSecure and Guardsquare for working alongside us on this journey. We'll continue working to keep MASTG at the cutting edge of mobile security."

Congratulations

On behalf of the full OWASP MAS project community, we congratulate vulnit on achieving MAS Advocate status. Their work on the MASTG v2 porting has been exactly the kind of deep, expert, sustained contribution that makes this project better for everyone. We look forward to continued collaboration and to seeing what comes next!

Want to learn more about the MAS Advocate program or get involved? See our contribution guidelines for MAS Advocates or reach out to the project leaders.

  • 2 min read

MASTG v2.0.0 Removes MAS Checklists

With MASTG v2, the OWASP MAS project has completed a major structural change in how MASVS, MASWE, and MASTG work together.

Previous MASTG releases included a generated MAS Checklist spreadsheet file. This file was useful for many assessment workflows. It gave testers a familiar way to track status, follow MASVS coverage, and jump from requirements to MASTG tests.

MASTG v2 does not include this spreadsheet file as an official release artifact.

This follows the same direction we already took when discontinuing the PDF version of the MASTG. Static release artifacts such as PDFs and spreadsheets were useful in the past, but they also require significant maintenance. They need dedicated generation logic, formatting, release handling, review, testing, and support. Over time, they can become separate product surfaces that need to be maintained in parallel with the actual project content.

We do not believe this is the best model for MASTG v2.

The industry has moved away from static documents as the primary way to consume technical guidance. Security teams now expect searchable, linkable, structured, continuously maintained content. They need data that can be filtered, mapped, integrated into tools, used in reports, and adapted to different assessment workflows. A fixed PDF or spreadsheet file is often less useful than authoritative structured content that can power many different views.

MASTG v2 was designed with this in mind. Tests, weaknesses, controls, profiles, techniques, tools, demos, knowledge articles, and best practices are now connected through structured metadata. The MAS website and project repositories are the authoritative source.

We recognize that some teams may want spreadsheet views, trackers, dashboards, or internal report templates. Since the source repositories now contain all the relevant data in a structured format, it can easily be ingested in other frameworks or tooling. Different organizations have different reporting needs, and custom generated views may often be more useful than one official spreadsheet.

Community Feedback

That said, we value community feedback! If the spreadsheet checklist is important to your workflow, we would like to hear from you. The data is available in a structured format already, but maybe there are issues with incorporating this into your workflow and a different format would be better. Please let us know by contributing to the open discussion!

https://github.com/OWASP/mastg/discussions/3923

For example, we are also interested in whether an official machine readable data artifact would be more useful than an spreadsheet file. A structured export could give the community a stable basis for building spreadsheets, dashboards, reporting tools, assessment trackers, and AI assisted workflows, without requiring the core project to maintain one specific spreadsheet format.

Existing spreadsheet checklist files from previous releases remain available for historical use. For MASTG v2, the MAS website and project repositories are the authoritative source.

  • 11 min read

MASTG v2.0.0 is Here

We just released MASTG v2.0.0, the first stable, non-beta release of the fully refactored Mobile Application Security Testing Guide. This is a milestone we have been building toward for three years, and it marks the completion of the most significant structural transformation in the project's history.

https://github.com/OWASP/mastg/releases/tag/v2.0.0

This post explains what MASTG v2 is, how it came to be, and what it means in practice — including how tests are written, how they connect to the rest of the framework, and what changed in this specific release.

Where We Came From

The original MASTG was written as a narrative guide: long chapters that mixed background, static analysis, dynamic analysis and code examples into a single flow. A chapter on "Testing Universal Links" could run 500 lines. A chapter on "Testing Anti-Debugging Detection" included bypass strategies, effectiveness criteria, and philosophical guidance on what "good enough" protection looks like. This was the right format for a book, and for years it was enormously useful as exactly that.

But the world changed. Organizations started building automation pipelines that needed to reference specific checks, not pages from a book. Compliance teams needed to trace a requirement in MASVS down to a test and from there to a specific piece of code. Tool authors wanted to know which technique a test relied on so they could determine whether their tool automated it. All of this was very hard to do with a narrative guide.

We began redesigning the framework in 2021, starting with the MASVS.

  • In August 2022, the project rebranded from OWASP MSTG to OWASP MAS, making explicit what the project had grown into: not just a testing guide, but a full framework comprising MASVS, MASTG, checklists, and a growing community supporting it.

  • MASVS v2.0.0 (April 2023) provided the structural foundation the MASTG redesign needed. MASVS v2 reorganized requirements around the classic categories (MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE) and moved the old L1/L2/R verification levels out of the standard itself and into the MASTG as Testing Profiles backed by concrete scenarios rather than abstract threat levels. The idea: controls stay platform-agnostic and stable; how you test them, and at what rigor, depends on context captured in the tests.

  • In October 2023, MASVS-PRIVACY extended this with a dedicated category and profile for privacy-relevant controls.

The MASTG refactor followed in two public milestones:

  • Part 1 in July 2023 introduced atomic tests and the profile system.
  • Part 2 in September 2023 introduced the full modular component model: tests, techniques, tools, and apps as individually addressable, stable-ID components. From there, the work of porting the 90+ v1 tests and building out hundreds of new ones began in earnest.

But even with atomic tests and a modular structure, something was missing: a layer between the high-level, platform-agnostic MASVS controls and the low-level, platform-specific MASTG tests. A MASVS control like "The app employs current strong cryptography and uses it according to industry best practices" is very abstract by design; it says nothing about what a concrete weakness looks like. A test like MASTG-TEST-0352 is very specific to Android anti-debugging and the relevant APIs and attributes involved. What was supposed to connect them?

In July 2024 we introduced the Mobile App Security Weakness Enumeration (MASWE): a structured catalogue of specific weaknesses in mobile applications, modeled after the role CWEs play in the broader software security industry. Each MASWE entry identifies a precise, platform-agnostic weakness and connects upward to the MASVS control it violates and downward to the platform-specific MASTG tests that check for it.

With MASWE in place, the full traceability chain was complete:

Every test in MASTG v2 carries a weakness: MASWE-XXXX field in its metadata. Every MASWE entry traces back to a MASVS control. The chain runs from a compliance requirement all the way to runnable code on a real device.

Here's how it works:

  1. MASVS Controls: High-level platform-agnostic requirements.

For example, "The app employs current cryptography and uses it according to best practices." (MASVS-CRYPTO-1).

  1. MASWE Weaknesses: Specific weaknesses, typically also platform-agnostic, related to the controls.

For example, "use of predictable pseudo-random number generation" (MASWE-0027).

  1. MASTG Tests: Each weakness is evaluated by executing tests that guide the tester in identifying and mitigating the issues using various tools and techniques on each mobile platform.

For example, testing for "insecure random API usage on Android" (MASTG-TEST-0204). Tests are backed by knowledge articles (MASTG-KNOW-****) and best practices (MASTG-BEST-****) that provide additional context and guidance for testers. They use techniques (MASTG-TECH-****) to perform the test steps.

  1. MASTG Demos: Practical demonstrations that include working code samples and test scripts to ensure reproducibility and reliability.

For example, a sample using Java's Random() instead of SecureRandom() (MASTG-DEMO-0007). Demos use specific tools (MASTG-TOOL-****) to perform the test steps.

What MASTG v2 Actually Is

MASTG v2 is now a knowledge graph of individually addressable, cross-linked components with stable IDs, structured metadata, and defined relationships to other components. The component types are:

Component ID Pattern Count
Tests MASTG-TEST-**** 285
Demos MASTG-DEMO-**** 152
Techniques MASTG-TECH-**** 167
Tools MASTG-TOOL-**** 135
Knowledge MASTG-KNOW-**** 140
Best Practices MASTG-BEST-**** 72
Apps MASTG-APP-**** 28

This modular approach allows us to maintain and update each component independently, ensuring that the MASTG remains current and relevant. For example, in our previous structure, the MASTG consisted of large test cases within a single markdown file. This was not only difficult to maintain but also made it challenging to reference specific tests; and it was impossible to have metadata for each test.

The new structure divides tests into individual pages (Markdown files with metadata), each with its own ID (MASTG-TEST-****) and links to relevant techniques (MASTG-TECH-****) and tools (MASTG-TOOL-****). This encapsulation ensures that each test is easily referenced and promotes reusability across all MAS components. For example, you can open a test and see what tools and techniques are being used, and soon you'll be able to do the same in reverse: open a tool or technique and see all the tests that use it. This deep cross-referencing can be extremely powerful when exploring the MASTG.

The New Test Format

The most consequential change in v2 is how individual tests are written.

A v1 test was a "book chapter". It would open with background, explain the mechanism under test, walk through static analysis, then dynamic analysis, often with inline code examples and Frida scripts woven into the prose.

This had many issues. Just to name a few:

  • It was hard to automate. A tool could not parse a 500-line chapter and know what to do.
  • It was hard to reference. A compliance team could not point to a specific test for a specific requirement. Sometimes they would reference a chapter, a section (with an anchor), a paragraph, sometimes a sentence.
  • It was hard to fail. A tester could not say "this test failed" without ambiguity. The chapter blended static and dynamic checks, so a tester could pass one part and fail another, but the chapter itself had no clear pass/fail criteria.
  • It had duplicate content. Many tests repeated the same background, the same Frida scripts, the same "how to decompile and analyze an app" instructions, and the same bypass guidance.
  • It was hard to maintain. A change in a technique or tool required updating dozens of chapters.
  • It was hard to review. A reviewer had to read a long chapter and decide whether it was correct, complete, and consistent with other chapters.

The old MASTG-TEST-0070 "Testing Universal Links" test ran 513 lines. It covered everything in one continuous narrative: entitlement checking, Apple App Site Association (AASA) file retrieval, link receiver method tracing, dynamic analysis with frida-trace and handoff behavior. This test has now become:

  • MASTG-TEST-0370 — Missing Input Validation in Custom URL Scheme Handlers
  • MASTG-TEST-0371 — Missing Source Validation in Custom URL Scheme Handlers
  • MASTG-TEST-0395 — Missing Input Validation in Universal Link Handlers

Each can now be referenced independently, automated independently, and fail independently.

Example: MASTG-TEST-0001 - Testing Local Storage for Sensitive Data

The old MASTG-TEST-0001 "Testing Local Storage for Sensitive Data" test ran 152 lines. It covered everything in one continuous narrative: shared preferences, internal storage, external storage, SQLite databases, and content providers. This has now become:

  • MASTG-TEST-0207 — Runtime Storage of Unencrypted Data in the App Sandbox
  • MASTG-TEST-0200 — Files Written to External Storage
  • MASTG-TEST-0201 — Runtime Use of APIs to Access External Storage
  • MASTG-TEST-0202 — References to APIs and Permissions for Accessing External Storage
  • etc.

And this list will keep growing as we continue to add new specific tests for each storage mechanism that were still missing in the v1 guide.

New MASTG v2 Tests

A v2 test is an atomic check. It has one thing to verify and it has a fixed structure:

  • Frontmatter metadata: platform (Android/iOS), type (static/dynamic/code/manual/hooks), weakness (MASWE-XXXX), profiles (L1, L2, R), knowledge articles, best practices, APIs involved.
  • Overview: describes what the test checks for
  • Steps: describes what you do using existing techniques (MASTG-TECH)
  • Observation: describes the raw output from your steps, before interpretation.
  • Evaluation: describes how you decide the pass/fail condition.

The example below shows this in practice:

  • It’s part of the default L1 and L2 security profiles.
  • It’s targeting Android.
  • The importance of the test is explained in MASWE-0007 (“Sensitive Data Stored Unencrypted in Shared Storage Requiring No User Interaction”).
  • The overview links to additional knowledge articles (MASTG-KNOW) and techniques (MASTG-TECH).
  • The steps link to existing techniques (MASTG-TECH).
  • A clear observation and evaluation are given.

On top of this we now have demos (MASTG-DEMO) tied to specific tests. They provide working code, expected outputs, and full automation artifacts. See below.

MASTG Demos

Each MASTG-DEMO consists of the following items:

  • A working sample app (Kotlin, Swift, or Objective-C) that exhibits the weakness under test.
  • A runnable script containing static analysis command, Frida script, or shell automation
  • A captured output.txt showing the exact expected output
  • An Evaluation section confirming what in the output constitutes a test failure

All demos are built and verified automatically on every push via GitHub Actions.

To ensure our guidelines are practical and reliable, we've developed new MAS Test Apps for both Android and iOS.

These simple skeleton applications are designed to embed code samples directly, allowing users to validate and experiment with the provided demos. This approach ensures that all code samples are functional and up-to-date, fostering a hands-on learning experience.

For example, to test for secure storage, MASTG-DEMO-0002 shows how to use dynamic analysis with Frida to identify the issues in the code. The demo includes:

  • a Kotlin code sample (ready to be copied into the app and run on a device)
  • the specific test steps for this case using Frida
  • the shell script including the Frida command
  • the Frida script to be injected
  • the output with explanations
  • the final evaluation of the test

You can run everything on your own device and validate the results yourself! Just clone the repository and navigate to the demo folder, install Frida on your computer and your Android device, and follow the steps.

These demos can also be used as experimental playgrounds to improve your skills and practice with different cases as you study mobile app security with the MASTG. For example, you can try to reverse engineer the app and see if you're able to find the same issues as the demo or you can try to fix the issues and see if you can validate the fix.

They are also great for advanced researchers and pentesters to quickly validate certain scenarios. For example, it's very common to find cases where Android behaves differently depending on the version or the manufacturer. With these demos, you can quickly validate if a certain issue is present on a specific device or Android version.

What This Means in Practice

For security testers: Every test now tells you exactly what to run, what to expect, and what constitutes a failure. You do not need to interpret prose or decide which parts of a chapter apply to your engagement. The Steps section is your test procedure. The Evaluation section is your reporting criterion.

For compliance and risk teams: Every test maps to a specific MASWE weakness, which maps to specific MASVS controls. You can trace a compliance requirement through the full chain: MASVS control → MASWE weakness → MASTG test. The IDs are stable and permanently resolvable.

For developers: The best-practices field in each test links to MASTG-BEST entries that describe how to build the control correctly. If your app fails MASTG-TEST-0326 (biometric auth fallback), MASTG-BEST-0031 tells you exactly how to fix it. Knowledge articles linked via knowledge: give you the platform-level understanding.

Thank you!

Thank you to everyone who contributed to this release and to the multi-year effort behind it.

Special thanks to Carlos Holguera (@cpholguera), the architect and heart of the MAS project, who kept the vision alive through the years and his persistence that has shaped it into what it is today.

We also want to give special recognition to a group of contributors whose sustained, high-quality involvement had a major impact on MASTG v2. This includes not only code and content contributions, but also review work, technical discussions, task force participation, consistency, and overall project support.

In alphabetical order:

Many others contributed along the way, and we are grateful for every meaningful contribution that helped move the project forward. Additional contributors and acknowledgements can be found in the release notes for v2.0.0, v1.9.0, v1.8.0, and earlier releases.

We cannot thank our MAS Advocates enough for their continuous contributions of quality content to the MAS project:

  • NowSecure
  • Guardsquare
  • vulnIt

Feedback Wanted

The v2 framework is complete. Now we build on it.

View the release on GitHub →

We encourage you to explore the new MASWE, MASTG tests and MASTG demos. Your insights and experiences are invaluable to us, and we invite you to share your feedback in our GitHub discussions to help us continue to improve. This way we can ensure that our resources are practical, reliable, and valuable for real-world application.

You can also contribute to the project by creating new weaknesses, tests, techniques, tools, or demos. We welcome all contributions and feedback, and we look forward to working with you to make the MAS project the best it can be.

  • 3 min read

OWASP MAScon is here!

For the very first time, the OWASP MAS team is organizing OWASP MAScon, a dedicated event built around the people, research, and practical work that drive mobile app security forward.

OWASP MAS has become a reference point for mobile app security through projects like MASVS, MASWE, and MASTG. Those resources shape how organizations assess mobile security, how testers run engagements, how developers build more securely, and how the industry talks about mobile risk. Now, for the first time, the team behind that work is bringing the community together for a focused conference experience, MAScon.

Even more importantly, MAScon is being held within OWASP Global AppSec EU 2026 in Vienna, Austria, on June 25 to 26, 2026, a flagship event that also celebrates 25 years of OWASP. The main conference page highlights the anniversary, the Vienna venue, and the June 25 to 26 conference dates, with training running June 22 to 24. Tickets are already available through the official event registration page. (Glue Up)

Organized by Carlos Holguera and Sven Schleier, OWASP MAS Leaders, MAScon is designed as a compact, high value program for practitioners who want substance, not fluff. The schedule brings together talks on offensive research, runtime internals, dynamic instrumentation, real world incidents, and the evolving tooling around mobile application testing.

The event opens with an introduction by the OWASP MAS team, with Carlos Holguera and Sven Schleier appearing as the organizers and opening speakers. From there, the program dives straight into technical depth:

  • Carlos Holguera and Stefan Bernhardsgrütter will present Let’s get frooky, Structured Mobile DAST with Frida, a session focused on the practical challenges of mobile penetration testing and how structured, Frida powered instrumentation can help assess hardened applications at runtime.

  • Sergi Alvarez (aka "pancake") will present Unveiling The Internals From Multiplatform Mobile Runtimes, taking attendees into the internals of frameworks such as Flutter, React, and Unity, and showing how low level reverse engineering techniques can recover code and data from release binaries.

  • Jan Seredynski will present Recent Mobile App Security Incidents from Real World Cases, walking through concrete incidents from real mobile applications and extracting practical lessons on what fails in production and which secure practices actually hold up.

  • Ole André Vadla Ravnås will present Meet the New Frida Frontend on the Block, introducing a new Frida frontend for macOS and iOS and exploring a more persistent, interactive, GUI driven workflow for live process analysis.

  • Jeroen Beckers will present Attacking ART, a talk centered on a lesser known technique targeting the Android Runtime through ODEX and VDEX manipulation, especially relevant when dealing with applications protected by strong resiliency controls.

The day concludes with a closing session by the OWASP MAS team, rounding out a memorable first edition.

What makes this launch especially exciting is that MAScon is not just another security event. It is a conference created by a community that has already had a real impact on the mobile ecosystem. The people involved are not just talking about mobile security, they are actively building the standards, methodologies, demos, and tooling that the industry uses.

That is why this first edition matters.

If you care about mobile app security, whether from the perspective of testing, research, engineering, product security, or standards, MAScon is the kind of event you want to watch closely. The first edition sets the tone, and it already looks like a strong one.

You can find more information here: