OWASP MASVS in practice: controls, profiles and testing

The OWASP MASVS (Mobile Application Security Verification Standard) is the OWASP standard for mobile app security. The latest release on the project's GitHub page is v2.1.0, published on January 18, 2024. It added the MASVS-PRIVACY group to the v2.0.0 structure released in April 2023.

This article explains how the standard is organized and how to use it on a real project: choosing a profile, turning controls into work, testing, and reporting.

Three documents, three jobs

The OWASP MAS project publishes three documents that work together.

The assessment page of the MASVS describes the split: the controls are "high-level and generic", while the MASTG gives recommendations and testing procedures per mobile OS. Not every weakness has a test yet. MASWE-0004, for example, states that the MASTG has no test for it so far, and the MAS-L1 profile page explains how to assess a weakness in that case: start from its "Modes of Introduction" and reuse related tests.

The 24 controls

MASVS v2.1 has 8 groups and 24 controls. The statements below are quoted from the standard.

Levels became profiles

MASVS v1 attached levels (L1, L2, R) to each requirement. The v2.0.0 release notes explain why v2 controls have none: the levels moved to the MASTG tests, so one control can be tested differently depending on the app. Their example is MASVS-STORAGE-1: storing data unencrypted in app internal storage is acceptable for L1, while L2 requires encryption.

The MAS Testing Profiles page defines four default profiles by attacker model:

The same page recommends a threat model to pick controls, and presents these defaults as the fallback when a custom profile is not feasible. Its examples put a news or calendar app at L1+P, and apps handling location, payment, health data, access tokens or API keys (a messenger, a health app) at L2+P. The examples add R when the app also carries business assets, such as intellectual property or ad revenue.

Using the MASVS on a project

1. Choose the profile. Write down what the app stores, what it can do on behalf of the user, and who would attack it. That answer picks L1 or L2, and whether R and P apply.
2. Turn controls into requirements. The profiles page lists a secure-by-design use: bring the selected controls into design and implementation from the start. A control such as MASVS-NETWORK-1 becomes concrete tickets: TLS everywhere, no cleartext exceptions, certificate validation left on.
3. Map each requirement to tests. Use the MASTG test pages for Android and iOS. Automate what can be automated in CI.
4. Keep manual review in the plan. The assessment page is explicit: "it is however not possible to complete MASVS verification using automated tools alone." Business logic, authentication flows and privacy disclosures need a person.
5. Report by control ID. For a certifying report, the same page asks for the scope of the verification, a summary of passed and failed tests, and how to fix the failures.

Common mistakes

Mixing v1 and v2 identifiers. v1 requirements were numbered like MSTG-STORAGE-1; v2 controls are named like MASVS-STORAGE-1. The numbers do not line up. MASWE-0004, for instance, maps to MSTG-STORAGE-1 and MSTG-CODE-2 in v1, and to MASVS-STORAGE-1 in v2. Check the mapping on the MASWE page before reusing an old checklist.

Testing only the app. The MASVS covers the client side only. The assessment page sends backend endpoints to the OWASP ASVS and to the Web Security Testing Guide.

Taking "MASVS certified" at face value. OWASP "does not certify any vendors, verifiers or software". A certification or trust mark claiming MASVS compliance is not vetted by OWASP.

Applying every control to every app. RESILIENCE controls matter when the user is the attacker. A threat model decides, and any deviation from the selected profile should be justified and documented, as the Using the MASVS page asks.