OWASP MASVS
Mobile Application Security Verification Standard at L1, L2, and R
The OWASP Mobile Application Security Verification Standard (MASVS) is the open standard that defines what a verified secure mobile application looks like, control by control. Pick a verification level (MASVS-L1 standard, MASVS-L2 defence in depth) and the optional resilience set (MASVS-R), test against the named controls, and produce a verification report that maps findings to MASVS rather than to a generic vulnerability list. SecPortal runs MASVS engagements as structured records with control-level traceability across the iOS app, the Android app, and the backend they call.
No credit card required. Free plan available forever.
OWASP MASVS: a verification standard for mobile, not just a finding list
The OWASP Mobile Application Security Verification Standard (MASVS) is the open standard that defines what a verified secure mobile application looks like, control by control. Where the OWASP Mobile Top 10 ranks the most common risks, MASVS describes which controls have to be in place and which tests have to pass for an iOS or Android application to be considered verified at a given level. MASVS is published by the Open Worldwide Application Security Project, is freely available under a Creative Commons licence, and is the underlying standard most regulated mobile procurement frameworks and consumer mobile assurance schemes cite when they require a mobile application security claim that goes beyond a finding list.
MASVS is most useful when buyers and consultancies want comparability across providers and a precise definition of depth. A mobile pentest report listing eight findings is not directly comparable to a different mobile pentest report listing five findings: the scope, the depth, the device matrix, and the control coverage may all differ. A MASVS verification at Level 2 against a named set of controls is comparable, because the controls are the same document for every provider. For the engagement-side checklist that runs alongside a MASVS verification, see the mobile application penetration testing checklist.
MASVS verification levels: pick the level on purpose
MASVS defines two baseline verification levels (L1 and L2) and a separate resilience set (R). The level is a contractual decision: a Level 1 engagement reported as Level 2 is a scope breach, and a Level 2 engagement reported as Level 1 is a value gap. Decide the level during pre-engagement, name it in the rules of engagement, and reflect it on every page of the verification report.
MASVS-L1 (standard security)
Defends against common mobile threats and applies to most consumer and business applications. Level 1 expects sound use of platform APIs, no sensitive data left in the clear on device, and no obviously broken authentication. It is verifiable through a mix of automated static analysis, dynamic testing on a real device, and a focused MASTG-aligned manual pass. A Level 1 verification report names the controls in scope and the deviations, and is honest about what was not exercised.
MASVS-L2 (defence in depth)
Adds defence in depth for applications handling regulated, financial, or otherwise sensitive data. Level 2 expects evidence-based testing of cryptography, authentication, session management, network communication, and platform interaction, mapped control by control rather than as a generic finding list. Level 2 is the default for banking apps, healthcare apps, and any consumer app whose backend holds regulated data. It pairs naturally with PCI MPoC, HIPAA technical safeguard evidence, and ISO 27001 Annex A.8.8.
MASVS-R (resilience against reverse engineering)
A separate set of controls layered on top of L1 or L2 for applications with anti-tampering, anti-reverse-engineering, or DRM-style requirements. MASVS-R is appropriate for payment apps, mobile gaming with revenue at stake, IP-sensitive enterprise apps, and any binary an adversary will spend real budget to attack. R is not an alternative to L1 or L2; it is an additional control set that says the binary itself resists inspection and modification beyond the platform default.
For a longer treatment of the engagement scaffolding (rules of engagement, scope, authorisation, retest mechanics) that supports a MASVS verification, see the pentest rules of engagement template and the pentest scoping calculator, which produces a defensible day estimate for mobile and backend assets together.
The MASVS control groups: what gets verified
MASVS is organised into eight control groups covering local storage through to privacy and an optional resilience layer. Every group contains numbered controls with explicit applicability for Level 1, Level 2, and (where relevant) MASVS-R. The verification report references those control identifiers directly, which is what makes MASVS engagements comparable across providers and over time.
MASVS-STORAGE
Local data storage on the device. Verify that secrets and personal data are stored using the platform key store (Android Keystore, iOS Keychain), that backups exclude sensitive items, that the app does not write to world-readable locations, and that paste buffers, screenshots, and crash logs do not retain regulated content. STORAGE is where the most common mobile findings cluster, and is also the chapter most directly cited by privacy regulators.
MASVS-CRYPTO
Cryptographic primitives used by the application. Verify that approved algorithms and key sizes are used, that random values come from a cryptographic source, that keys are derived and stored under the platform key store rather than hard-coded, and that custom crypto has not been written where a vetted library would have done. CRYPTO underwrites PCI DSS, HIPAA, and GDPR technical control evidence when MASVS is the testing standard.
MASVS-AUTH
Authentication and session management. Verify that the app supports the backend authentication flow correctly (OAuth, OIDC, SAML), that biometric and device-bound credentials are bound to the platform key store, that step-up authentication exists for sensitive actions, and that session tokens are scoped, refreshable, and revocable. AUTH is the chapter most engagements stress test first because it ties the device to the backend identity surface.
MASVS-NETWORK
Network communication between the app and its backend. Verify TLS configuration, certificate pinning where the threat model justifies it, rejection of mixed and cleartext content, handling of certificate errors, and the app behaviour when a proxy or untrusted CA is present. NETWORK is the chapter that catches the certificate pinning bypasses, downgrade attacks, and proxy trust issues that mature mobile reports almost always carry.
MASVS-PLATFORM
Interaction with the underlying mobile platform. Verify intent and URL scheme handling on Android, universal links on iOS, exported component permissions, WebView configuration, deep link authentication, and IPC boundaries. PLATFORM is the chapter that distinguishes a mobile app from a web app: every finding here is rooted in something the platform exposes that a browser does not.
MASVS-CODE
Code quality, dependency management, and build pipeline hygiene. Verify that third party libraries are tracked and patched, that debug code paths are removed in production builds, that the binary is built with the platform-recommended hardening flags, and that CI/CD has not embedded secrets into the artefact. CODE is the chapter that ties verification back to the build pipeline rather than only the runtime artefact.
MASVS-RESILIENCE (optional MASVS-R)
Anti-tampering, anti-reverse-engineering, and integrity checks. Verify root and jailbreak detection, runtime application self-protection where applicable, anti-hooking and anti-debugging defences, and binary integrity checks. RESILIENCE is the layer applied on top of L1 or L2 when the threat model includes a motivated attacker willing to spend budget on the binary itself.
MASVS-PRIVACY
Data minimisation, consent, and transparency obligations. Verify that the app collects only the data it documents, that consent is granular and revocable, that third party SDKs are inventoried with their data flows, and that platform privacy nutrition labels reflect the implementation. PRIVACY is the chapter that ties MASVS verification to GDPR, CCPA, and platform store policy expectations.
The control set is broad on purpose. A verification claim that exercises only STORAGE and NETWORK is a partial verification, not a full MASVS engagement at the declared level. When scoping a MASVS test, write down the groups in scope and the groups explicitly out of scope, so the report cannot be read as a stronger claim than was tested. For deeper context on how mobile findings flow into a structured engagement, see the API security testing use case (the backend the mobile app calls is rarely out of scope) and the API security testing checklist.
MASVS reporting expectations: the deliverable, not an export
A MASVS verification report is a structured deliverable, not a wrap-up. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and evidence density determine whether the verification was actually useful.
- Verification level claim (MASVS-L1, MASVS-L2, with or without MASVS-R) declared up front, with the reason the level was chosen rather than a higher or lower one
- In-scope MASVS controls listed by group and identifier (for example MASVS-STORAGE-1, MASVS-CRYPTO-2), with explicit deviations documented for any control excluded with a reason
- Asset list named (the iOS bundle identifier, the Android package name, the build versions tested, the device and OS versions, and the backend environment in scope)
- Findings logged against the MASVS control they evidence, with a CWE identifier where applicable, the OWASP Top 10 or MASTG test reference, and a CVSS 3.1 vector for severity
- Evidence inline with each finding: command output, decompiled snippet, request and response, screenshot, or short clip, retained on the same record so a reviewer can validate the result without asking for the working file
- Remediation guidance written for the mobile engineering audience that will fix the finding, citing the MASVS control and the platform API rather than restating the vulnerability description
- Retest scope agreed at kickoff (the retest count, the retest window, and the verification method per finding) so the verification report can include verified-fixed status without renegotiation
- Closure record covering the original finding, the proposed fix, the retest evidence on a clean device build, and the final outcome, so the verification claim is a record rather than a pdf attached to an email
For deeper context on how to structure a pentest report end to end, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the executive summary, technical body, and remediation roadmap from the underlying engagement, findings, and verification level claim, citing the MASVS controls that were exercised rather than starting from a blank template.
How MASVS sits next to ASVS, MASTG, the Mobile Top 10, and PCI MPoC
MASVS is rarely used in isolation. It is the requirement set that other documents cite, run against, or wrap. The contrast below is a working view, not a buyer comparison: the practitioner question is which standards to pair MASVS with, not which to pick instead of it.
MASVS vs ASVS
OWASP ASVS is the verification standard for web applications; MASVS is the verification standard for mobile applications. The two share the same level structure (L1 standard, L2 advanced) and the same engagement shape, but MASVS adds chapters specific to mobile platforms (storage on device, platform interaction, code and binary hygiene, resilience). Engagements covering both web and mobile in one scope typically declare an ASVS level for the web tier and a MASVS level for the mobile tier separately, on the same engagement record, with findings mapped to the right standard.
MASVS vs MASTG
MASVS is the standard; the OWASP Mobile Application Security Testing Guide (MASTG) is the how-to reference. MASVS says which control is verified; MASTG describes how to test for the underlying weakness with concrete commands, tooling, and platform notes. Mature mobile engagements pair MASVS (the requirement set) with MASTG (the test technique reference) and CVSS (the severity language).
MASVS vs OWASP Mobile Top 10
The OWASP Mobile Top 10 is a ranked list of common mobile risks. MASVS is a verification standard that says, control by control, what a verified secure mobile application looks like. The two compose: a Mobile Top 10 finding maps to one or more MASVS controls, and a MASVS verification covers the broader requirement set. A pentest scoped to the Mobile Top 10 covers the headline risks; a MASVS engagement covers the requirement set and produces a verification report rather than a finding list.
MASVS vs PCI MPoC
PCI MPoC (Mobile Payments on COTS) is a payment industry standard that mandates mobile payment app controls and is operationalised through accredited assessor labs. MASVS sits underneath as the technical verification standard. Many MPoC submissions cite MASVS controls as the technical evidence layer; conversely, a strong MASVS engagement against a payment app produces most of the technical artefacts MPoC needs without rerunning the test.
Buyers procuring a mobile engagement under a regulated framework should pair MASVS with OWASP ASVS for the web tier of the same product, with PTES as the engagement-level methodology, and with ISO 27001 Annex A.8.8 (technical vulnerability management) when the verification feeds an ISMS audit. For payment-card mobile apps, the same MASVS engagement also feeds PCI DSS technical evidence for the consumer-facing surface.
MASVS for AppSec teams, pentest firms, and DevSecOps programmes
MASVS is read differently depending on which side of the engagement you sit on. AppSec teams use MASVS as the internal bar that the mobile engineering team builds against, and as the structure that triages findings from SAST, SCA, and dynamic mobile testing into one comparable picture. Pentest firms use MASVS as the standard their mobile report is written against, and as the language that lets clients compare engagements over time. DevSecOps programmes use MASVS as the gate their mobile CI/CD pipeline is calibrated against, especially MASVS-CODE (dependency hygiene, hardening flags) and MASVS-NETWORK (TLS, pinning).
The persona-specific entry points are SecPortal for application security teams, SecPortal for cybersecurity firms, and SecPortal for DevSecOps teams. Each anchors a different view of the same MASVS engagement record.
For firms that focus exclusively on iOS and Android testing rather than running mobile as one of several practices, the SecPortal for mobile security consultancies page covers the operating model that fits a specialist mobile pentest practice, including finding evidence fields tuned to MASVS controls and the retest workflow that pairs verification to the original finding across each new app build.
Where SecPortal fits in a MASVS verification engagement
SecPortal is the operating layer for a MASVS verification engagement. The platform handles scope, level claim, control coverage, backend authenticated DAST evidence, mobile codebase SAST and SCA evidence, finding triage, retests, and the final deliverable so the engagement runs as a single workflow rather than a long email thread with attachments and screenshot zips. For consultancies running MASVS engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals.
- Engagement management captures the MASVS verification level, the in-scope control groups, the iOS and Android binaries under test, the backend environment, the rules of engagement, the testing window, and the agreed retest scope as a structured record so the engagement scaffold is the workflow rather than a contract attachment
- Findings management stores each finding with a CVSS 3.1 vector, severity, evidence, owner, OWASP Top 10 category, CWE identifier, and a free-text mapping field for the MASVS control being verified, so the verification report writes itself from the underlying records
- Authenticated scanning runs DAST modules against the backend the mobile app calls on the same engagement record, with credentials stored encrypted at rest under AES-256-GCM, so MASVS-AUTH and MASVS-NETWORK evidence covers the device and the API surface together
- Code scanning runs SAST and SCA against the mobile codebase via the Git provider connection (GitHub, GitLab, Bitbucket), so MASVS-CODE evidence (dependency hygiene, hardening flags, secret scanning) is captured against the same engagement as the runtime testing
- AI-assisted reports compose the executive summary, technical body, and remediation roadmap from the live engagement, findings, and verification level claim, citing the MASVS controls that were exercised rather than starting from a blank template
- Client portal delivers the verification on the consultancy subdomain so the buyer sees the live engagement, retests, and closure status rather than a frozen PDF, with branded styling that matches consumer and enterprise mobile reporting expectations
- Compliance tracking lets one MASVS engagement satisfy framework mappings to ISO 27001 Annex A.8.8, SOC 2 Trust Services Criteria, PCI MPoC, and HIPAA technical safeguard evidence without rebuilding the bundle for each audit
Looking for the engagement workflow itself, end to end? The penetration testing use case and the pentest project management use case capture how SecPortal turns a MASVS-shaped engagement into a structured record covering scope, level claim, findings, retests, and the deliverable. For the retest mechanics specifically, see the pentest retesting use case.
For procurement-side context (how buyers should compare MASVS aligned proposals on effective day rate, control coverage, retest policy, and reporting depth), see the pentest pricing models research and the pentest scope creep research, which together cover the contract structure that holds a MASVS verification claim together over time.
Key control areas
SecPortal helps you track and manage compliance across these domains.
MASVS-STORAGE: Local data on device
Verify that secrets and personal data are stored using the platform key store (Android Keystore, iOS Keychain), that backups exclude sensitive items, that the app does not write to world-readable locations, and that paste buffers, screenshots, and crash logs do not retain regulated content. STORAGE is where the most common mobile findings cluster, and is also the chapter most directly cited by privacy regulators.
MASVS-CRYPTO: Algorithms, keys, randomness
Verify that approved algorithms and key sizes are used, that random values come from a cryptographic source, that keys are derived and stored under the platform key store rather than hard-coded, and that custom crypto has not been written where a vetted library would have done. CRYPTO underwrites PCI DSS, HIPAA, and GDPR technical control evidence when MASVS is the testing standard.
MASVS-AUTH: Authentication and session management
Verify that the app supports the backend authentication flow correctly, that biometric and device-bound credentials are bound to the platform key store, that step-up authentication exists for sensitive actions, and that session tokens are scoped, refreshable, and revocable. AUTH ties the device to the backend identity surface.
MASVS-NETWORK: TLS, pinning, proxy behaviour
Verify TLS configuration, certificate pinning where the threat model justifies it, rejection of mixed and cleartext content, handling of certificate errors, and the app behaviour when a proxy or untrusted CA is present. NETWORK catches the certificate pinning bypasses, downgrade attacks, and proxy trust issues that mature mobile reports almost always carry.
MASVS-PLATFORM: IPC, deep links, WebView
Verify intent and URL scheme handling on Android, universal links on iOS, exported component permissions, WebView configuration, deep link authentication, and IPC boundaries. PLATFORM is the chapter that distinguishes a mobile app from a web app: every finding here is rooted in something the platform exposes that a browser does not.
MASVS-CODE: Dependencies and build hygiene
Verify that third party libraries are tracked and patched, that debug code paths are removed in production builds, that the binary is built with the platform-recommended hardening flags, and that CI/CD has not embedded secrets into the artefact. CODE ties verification back to the build pipeline rather than only the runtime artefact.
MASVS-RESILIENCE (R): Anti-tampering and integrity
Verify root and jailbreak detection, runtime application self-protection where applicable, anti-hooking and anti-debugging defences, and binary integrity checks. RESILIENCE is the layer applied on top of L1 or L2 when the threat model includes a motivated attacker willing to spend budget on the binary itself.
MASVS-PRIVACY: Data minimisation and consent
Verify that the app collects only the data it documents, that consent is granular and revocable, that third party SDKs are inventoried with their data flows, and that platform privacy nutrition labels reflect the implementation. PRIVACY ties MASVS verification to GDPR, CCPA, and platform store policy expectations.
Run MASVS verification with control-level traceability
Pick the level, test the named controls, and ship a verification report mapped to MASVS rather than a generic finding list. Start free.
No credit card required. Free plan available forever.