OWASP MASVS and MASTG: what a mobile app security test should cover

The OWASP Mobile Application Security Verification Standard is the requirement set for mobile apps: what a secure app should do, stated independently of platform. Version 2.0.0, released in April 2023, rewrote it substantially, removing overlaps and leaving the low-level detail to the test guide. Version 2.1.0, released in January 2024, added an eighth group, MASVS-PRIVACY, and is the current release.

The groups are labelled MASVS-STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY, and each contains numbered controls — MASVS-STORAGE-1, for instance, is simply that the app securely stores sensitive data. There are twenty-four in all. They are deliberately high-level, because a control has to hold for Android and iOS, native and cross-platform, and for whatever the platforms change next year.

That abstraction is the point, and it is also why a report that cites only the MASVS has said less than it seems. A control is an outcome. What was actually done to verify it lives one layer down.

Earlier versions of the MASVS assigned each requirement to a level — L1, L2 or R. Version 2.0 removed the levels from the standard and moved them into the testing guide as profiles, so that the same control can be tested differently depending on the threat. The example OWASP gave is storage: for an L1 app it can be acceptable to keep data unencrypted in the app’s private storage, where L2 requires it to be encrypted.

There are four default profiles, and each is defined by who the attacker is. MAS-L1 treats other apps on the device as the adversary and trusts the operating system. MAS-L2 assumes the operating system cannot be trusted and that an attacker may have the device in hand. MAS-R treats the user as the adversary — the reverse engineer or the cheat — and exists to protect the app’s own business logic. MAS-P, added in 2025, is not attacker-centric at all; it is a privacy baseline.

Choosing a profile is a decision about your threat model, not a quality tier, and OWASP is clear that the goal is not to comply with every profile. A banking or health app is an L2 conversation. A game with a competitive economy may need R and very little else. The profile belongs in the proposal, because it decides what is tested.

The Mobile Application Security Testing Guide is the method: the techniques, tools and individual tests for verifying each control on Android and iOS. Version 2.0.0, released on 30 June 2026, completed a multi-year restructuring that split the guide into separately referenceable parts. Each test now has its own identifier in the form MASTG-TEST followed by a number, and links to a weakness in the new Mobile Application Security Weakness Enumeration, which in turn links to the MASVS control.

That chain — control, weakness, test — is what makes a mobile report checkable. A finding that cites the MASVS control and the MASTG test that produced it can be traced by somebody who was not in the room, and so can a control marked as passed.

It also gives you the question to ask before you buy. Which MASVS version, which profile, and will findings and passed controls be mapped to MASTG tests? A tester who works to the guide can answer all three in a sentence.

The MASVS states plainly that it covers only the security of the mobile app — the client side — and contains no controls for the remote endpoints the app talks to. The MASTG says the same: testing the app’s remote endpoints is not covered, and it points to the Web Security Testing Guide for that, as the MASVS points to the ASVS.

This matters more than it sounds. The MASVS-AUTH group itself notes that authentication and authorisation must be enforced on the remote endpoint. An app can pass every MASVS control and still sit in front of an API that returns any user’s records to anyone who changes an identifier — because that flaw is in the server, and the standard did not look there.

So a mobile test that stops at the app has tested the half that holds the least. When you scope one, list every API host the app calls, put them in scope with their own authorisation, and make sure the tester has accounts for at least two roles. The OWASP guidance for MASVS verification asks for exactly that: access to at least one user account for each role.

A mobile test has two halves. Static analysis takes the app apart without running it: decompiling the package, reading its configuration and permissions, finding hardcoded secrets, weak cryptography and libraries with known vulnerabilities. Dynamic analysis runs it on a device the tester controls, intercepts its traffic, and watches what it writes to storage and logs; the MASTG notes this is done both at the platform layer and against the backend services.

Automated mobile scanners are useful for the first pass and OWASP encourages them. It is equally clear that MASVS verification cannot be completed with automated tools alone, and that running a tool and reporting its failures is not sufficient evidence that a control was tested. The guide also warns about a particular false positive: web scanners pointed at a mobile backend report browser-only issues that do not apply to an app.

One more thing to know before you see a badge. OWASP does not certify vendors, testers or apps against the MASVS. A firm can test against it and report which controls were verified; nobody can issue a certification in OWASP’s name.