OWASP MASVS & MASTG

What MASVS and MASTG are

MASVS is OWASP’s security requirements checklist for mobile apps. MASTG is the companion testing guide that tells you how to verify each requirement. Together, they give you a structured way to assess mobile app security instead of ad-hoc testing.

The Mobile Application Security Verification Standard (MASVS) defines specific security requirements organized into categories: storage, cryptography, authentication, network communication, platform interaction, code quality, and resilience. Each requirement has an ID (like MASVS-STORAGE-1) and a clear pass/fail criterion.

The Mobile Application Security Testing Guide (MASTG) pairs with MASVS by providing test cases for each requirement. A MASTG test case tells you what to look for, which tools to use, how to reproduce the issue on both iOS and Android, and what a passing implementation looks like. The project moved from “MSTG” to “MASTG” in the 2023 refactor, along with a complete restructuring of test IDs.

OWASP updates both documents through community contributions. The current version reflects the mobile threat model as of late 2024, with expanded coverage of privacy requirements, supply chain risks, and platform-specific hardening controls.

If you are responsible for mobile app security and need to prove it to auditors, regulators, or customers, MASVS is where you start. It gives everyone a shared vocabulary and measurable criteria.

MASVS verification levels

MASVS defines two verification levels and a resilience category. Not every app needs every level.

L1: Standard Security

L1 is the baseline. Every production mobile app should meet L1 regardless of what it does. These requirements cover the fundamentals: no hardcoded credentials, proper TLS configuration, secure local storage, appropriate permissions, and basic input validation.

Meeting L1 means your app does not have the obvious mistakes that automated scanners and casual attackers find in minutes. Think of it as the security equivalent of not shipping debug builds to production.

Most L1 requirements can be verified with automated tools. MobSF and Oversecured cover most L1 checks out of the box.

L2: Defense-in-Depth

L2 adds requirements for apps that handle sensitive data or operate in hostile environments. Banking apps, healthcare apps, government apps, and anything processing payment information should target L2.

The additional requirements include certificate pinning, biometric authentication security, proper session management, anti-debugging protections, and more thorough cryptographic implementations. L2 assumes that attackers are motivated and will spend time reverse-engineering the app.

L2 verification requires more manual testing. Automated tools can check whether certificate pinning is present, but verifying that the implementation resists Frida-based bypass attempts needs a human with a test device.

R: Resilience Against Reverse Engineering

The R category is separate from L1 and L2. It covers binary protection, code obfuscation, anti-tampering, root/jailbreak detection, and debugger detection. These controls make reverse engineering harder (not impossible — nothing is impossible with enough effort).

R requirements apply to apps where the binary itself is a target: DRM-protected content, payment apps, apps with proprietary algorithms, or apps where client-side logic bypass would cause direct financial harm.

Zimperium zScan specializes in validating resilience controls. Talsec provides a RASP SDK that implements many R requirements at the library level.

Walking through each MASVS category

Here is what each MASVS category covers and what to focus on when testing.

MASVS-STORAGE: Data Storage

How the app stores data on the device. The requirements check that sensitive data is not written to plaintext files, logs, backups, or clipboard. On Android, this means encrypted SharedPreferences or Jetpack Security EncryptedFile. On iOS, this means Keychain with appropriate protection classes, not NSUserDefaults.

This category produces the most findings in assessments. Developers underestimate how many places data ends up on a mobile device: keyboard caches, screenshot caches, web caches, analytics logs, crash reports.

MASVS-CRYPTO: Cryptography

Correct use of cryptographic primitives. No hardcoded encryption keys, no deprecated algorithms (MD5, SHA-1 for security purposes, DES), proper key management through the platform keystore (Android Keystore, iOS Secure Enclave).

The common mistake is not weak algorithms but key management. An app using AES-256-GCM with a key embedded in the binary provides zero real protection. The algorithm is fine. The key storage is the problem.

MASVS-AUTH: Authentication and Authorization

Authentication flows, session management, and access control. Requirements cover proper credential handling, biometric authentication implementation, session timeout, and server-side authorization checks.

The biggest risk here is client-side authorization logic. If the app hides a menu item based on a local role check rather than server-side enforcement, any attacker with Frida can flip that flag and access the hidden functionality.

MASVS-NETWORK: Network Communication

TLS configuration, certificate validation, certificate pinning, and protection against network-based attacks. The app should use TLS 1.2 or higher, validate certificates properly, and ideally implement certificate pinning for sensitive connections.

Test this by setting up a proxy with a custom CA certificate. If you can intercept traffic without any additional steps, the app trusts arbitrary CAs. If pinning blocks the proxy, test whether the pinning can be bypassed with standard Frida scripts. The difficulty of bypass is part of the assessment.

MASVS-PLATFORM: Platform Interaction

How the app interacts with the mobile platform. Covers IPC (intents on Android, URL schemes on iOS), WebView security, permission usage, and deep link handling. Exported Android components without proper permission checks are the most frequent finding in this category.

On iOS, check how the app handles universal links and custom URL schemes. On Android, test exported activities, broadcast receivers, and content providers with crafted intents.

MASVS-CODE: Code Quality

General code quality and build configuration. Debug settings disabled in production, proper error handling, stack trace suppression, and security-relevant compiler flags. Also covers third-party library security and update management.

MobSF covers most code quality checks automatically. The manual effort here is reviewing third-party SDK behavior and verifying that the app handles edge cases without leaking information.

MASVS-RESILIENCE: Resilience

Anti-tampering, obfuscation, root/jailbreak detection, debugger detection, and runtime integrity checks. This category maps to the R verification level. These controls do not fix vulnerabilities — they raise the bar for attackers trying to reverse-engineer or tamper with the app.

Testing here means actively trying to bypass the controls. Can you attach Frida to the process? Can you modify the APK and re-sign it? Does the app detect a rooted device? How many seconds does it take to bypass the detection? Guardsquare provides tools for both implementing and testing resilience controls.

Mapping MASVS requirements to automated tools

No single tool covers every MASVS requirement, but here is how the major tools map to categories.

MobSF covers STORAGE, CRYPTO, CODE, and parts of NETWORK and PLATFORM through static analysis. Its dynamic analysis mode adds runtime checks for storage and network behavior. Best for L1 baseline verification. Free and open-source.

NowSecure covers all categories including deep STORAGE analysis, NETWORK testing with real traffic interception, and PLATFORM interaction checks. Strong MASVS alignment with direct requirement mapping in reports. Commercial.

AppKnox covers STORAGE, CRYPTO, NETWORK, CODE, and parts of AUTH through combined SAST, DAST, and API testing. Maps findings to MASVS categories plus compliance frameworks like PCI-DSS and HIPAA. Commercial.

Oversecured excels at STORAGE, PLATFORM, and CODE categories through deep static analysis. Covers 175+ Android and 85+ iOS vulnerability categories, many of which map directly to MASVS requirements. Commercial.

esChecker by eShard is specifically aligned to MASVS and MASTG test cases. It provides DAST with IAST capabilities and maps results directly to MASVS requirements with remediation checklists. Commercial.

Zimperium zScan covers NETWORK, RESILIENCE, and parts of STORAGE and CODE. Specializes in validating security controls rather than finding code-level vulnerabilities. Commercial.

For a complete assessment, most teams combine an automated scanner for L1 coverage with manual testing for L2 and R requirements.

Using MASTG test cases in practice

MASTG test cases are organized by MASVS category and platform. Each test case has an ID, a description of what to test, step-by-step instructions, and expected results. Here is how to actually use them.

Finding the right test cases

Start from the MASVS requirement you want to verify. Each requirement links to one or more MASTG test cases. For example, MASVS-STORAGE-1 (“The app securely stores sensitive data”) links to test cases covering SharedPreferences analysis, Keychain inspection, SQLite database checks, and log file review.

The OWASP mobile security project maintains these mappings on their GitHub repository and website. Bookmark the mapping table — you will reference it constantly.

Running a test case

Take MASTG-TEST-0001 (testing local data storage on Android) as an example. The test case tells you to install the app, use it normally, then inspect the app’s data directory at /data/data/<package_name>/. Check SharedPreferences XML files, SQLite databases, and the cache directory for sensitive data.

The test case specifies which tools to use (adb, sqlite3, or objection’s file exploration), what to look for (authentication tokens, personal data, encryption keys in plaintext), and what constitutes a pass or fail.

Adapting test cases to your context

MASTG test cases are generic. Your app has specific data flows and sensitive values. Before running through the checklist, define what counts as “sensitive data” for your app. An e-commerce app’s sensitive data includes payment tokens and addresses. A healthcare app’s sensitive data includes medical records and insurance IDs. Tailor the test cases to check for your specific data types.

Tracking results

Create a spreadsheet or checklist mapping each MASVS requirement to its test result: pass, fail, not applicable, or not tested. Include the MASTG test case ID, the platform (iOS or Android), evidence (screenshots or logs), and remediation status. This becomes your compliance artifact.

Building a MASVS compliance workflow

Making MASVS compliance repeatable rather than a one-time assessment means building it into how you ship code.

Automated checks in CI/CD

Add MobSF or a commercial scanner to your build pipeline. On every build, scan the APK or IPA for MASVS violations. Set quality gates: block releases when MASVS-CRYPTO or MASVS-STORAGE requirements fail. This catches regressions automatically.

Oversecured and AppKnox both support CI/CD integration that can fail builds on specific findings. MobSF has a REST API that you can call from any CI system.

Pre-release manual assessment

Before major releases, run through the MASTG test cases that automated tools cannot cover. This includes L2 requirements like certificate pinning bypass testing, authentication flow review, and runtime behavior analysis. Budget one to three days per platform for a thorough manual pass.

Continuous monitoring

For apps in production, NowSecure and Data Theorem offer continuous monitoring that rescans your app periodically and alerts on new findings. This catches issues introduced by third-party SDK updates or platform changes that affect your app’s security posture.

Maintaining evidence

Auditors want proof. Keep records of every automated scan result, manual test outcome, and remediation action. Store them in a format that maps to MASVS requirement IDs so you can pull a compliance report for any point in time.

A quarterly review cadence works for most teams: automated scanning on every build, manual assessment before major releases, and a full MASVS compliance review every quarter. Adjust based on your risk profile — financial apps may need monthly manual reviews.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.