An auditor asks one question that stops most teams cold. Does your app meet OWASP MASVS? People nod, then realise they cannot name a single control they have actually verified. MASVS is the most cited mobile security standard in the world and one of the least understood by the teams expected to follow it.
This guide fixes that. It explains what MASVS is, walks all eight control groups in the current version with a concrete pass and fails for each, and gives you a self-check you can run today, before you spend a rupee or a dirham on tooling.
It is written for AppSec leads, compliance officers, and developers who need to move from quoting the standard to applying it.
What is MASVS?
MASVS stands for the OWASP Mobile Application Security Verification Standard. It is a community built standard, maintained by OWASP, that defines what a secure mobile app should do. Treat it as the baseline your app is measured against.
It is not a list of attacks. That is the job of its companion, the OWASP Mobile Application Security Testing Guide, known as MASTG, which explains how to test each requirement. MASVS sets the what. MASTG covers the how.
OWASP restructured the standard in 2023 around control groups rather than the old numbered levels. Version 2.1 added a dedicated privacy group, which is the change most teams have not caught up with yet.
MASVS vs the OWASP Mobile Top 10
These two get confused constantly. The Mobile Top 10 is an awareness list of the most common mobile risks. MASVS is the verification standard you build and test against. The Top 10 tells you what tends to go wrong. MASVS tells you what good looks like. You want both.
The eight MASVS control groups, with a pass and a fail for each
Here is where competitor articles stop, usually after listing the group names. The names alone do not help a developer. What helps is seeing what passing and failing actually look like.
| Control group | What it verifies | Fail example | Pass example |
| MASVS-STORAGE | Sensitive data is stored safely on the device | An auth token is saved to SharedPreferences in plain text | The token is kept in the Android Keystore or iOS Keychain and never logged |
| MASVS-CRYPTO | Cryptography follows current best practice | A hardcoded AES key sits in the source code | Keys are generated and held in the Keystore or Keychain, using modern algorithms |
| MASVS-AUTH | Authentication and authorization are handled correctly | A biometric lock is checked only on the client and can be bypassed by tampering | Biometric unlock gates a server issued token, and the server enforces access |
| MASVS-NETWORK | Network traffic is protected in transit | The app allows cleartext HTTP or trusts any certificate | All traffic uses TLS with proper certificate validation, and cleartext is disabled |
| MASVS-PLATFORM | The app uses platform features and other apps safely | An exported Activity accepts sensitive intents with no permission | Components are not exported unless needed and are permission protected |
| MASVS-CODE | Code and dependencies are kept clean and current | A release ships with debug logging on and a library with a known CVE | Debug code is stripped, dependencies are scanned and updated, and input is validated |
| MASVS-RESILIENCE | The app resists reverse engineering and tampering | A banking app runs unmodified on a rooted device with a hooking tool attached | The app detects rooting and tampering and applies obfuscation as defense in depth |
| MASVS-PRIVACY | User privacy is respected and protected | Precise location and device IDs are shared with an ad SDK without consent | Only necessary data is collected, disclosed, and gated behind user consent |
Run this MASVS self-check before you pay for a tool
You can sanity check several of these areas yourself in an afternoon with free tools. This is the MASVS checklist most teams never run.
- Decompile your APK with jadx or apktool and search for keys, tokens, and passwords. This tests STORAGE and CRYPTO.
- Open the AndroidManifest and check for usesCleartextTraffic, a debuggable flag, and exported components with no permission. This tests NETWORK, PLATFORM, and CODE.
- Confirm sensitive data uses EncryptedSharedPreferences or the iOS Keychain, not a plain file. This tests STORAGE.
- Route the app through a proxy such as mitmproxy and watch for cleartext traffic or a missing certificate check. This tests NETWORK.
- List every third party SDK and check what data each one collects and sends. This tests PRIVACY.
- Cross check your dependencies against known CVEs. This tests CODE.
This catches the obvious failures. It does not produce the evidence trail a NESA, RBI, or PCI DSS audit expects, which is a full assessment mapped control by control. But it tells you how much work sits ahead before you pay for anything.