An OWASP MASVS mobile security testing checklist is a structured way to verify an app against the eight MASVS control groups, using the companion MASTG for the actual test cases and combining static analysis of the build with dynamic testing on a device you own. The MASVS says what secure means across storage, cryptography, authentication, network, platform, code, resilience, and privacy; the MASTG gives you the concrete checks to prove each one. For an auditor, the two areas that come up most are data storage, where you confirm no sensitive data sits in insecure locations, and cryptography, where you confirm strong algorithms and safe key handling. Run the checks on your own build and device, map findings back to the control groups, and remediate by severity.
Short answer
A MASVS testing checklist verifies your app against the eight control groups using the MASTG's test cases. Per the OWASP MASVS, the groups are MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE, and MASVS-PRIVACY. Per the OWASP MASTG, you test each with static analysis of the build and dynamic analysis at runtime on a device you own. For data storage, confirm no sensitive data is in shared preferences, files, databases, or logs in plaintext. For cryptography, confirm strong, standard algorithms and that keys are not weak or hardcoded. Map every finding to a control group and fix by severity.
What a MASVS testing checklist is
A MASVS testing checklist is the audit form for mobile security: a list of the controls an app should meet, grouped by area, that you check off by testing. The MASVS defines the requirements across eight control groups covering data storage, cryptography, authentication, network, platform interaction, code quality, resilience, and privacy, so the checklist has a place for every category of mobile risk. It is the standard against which you judge whether an app is secure, giving structure to an audit rather than testing at random.
The checklist is paired with a testing guide, because knowing the requirement is not the same as verifying it. The MASTG, the testing companion to the MASVS, provides the concrete test cases and techniques for each control, so where the MASVS says sensitive data must not be stored insecurely, the MASTG tells you how to look. So a real MASVS checklist is two things working together: the control groups that define what to check, and the test cases that tell you how to check them. An audit works through the groups, applying the tests, and records a pass or fail with evidence for each.
Setting up the test environment
MASVS testing needs a controlled environment where you can both inspect the build and run the app under observation, on hardware you own. The two halves are static analysis, examining the app package itself by decompiling it and reviewing its code, resources, and manifest, and dynamic analysis, running the app on a device or emulator and watching its behavior, files, and network traffic. A defense-in-depth or resilience assessment also needs a rooted or jailbroken test device so you can attempt bypasses, which requires full control of the device.
Set it up responsibly. Use a device or virtual instance you own, keep it isolated from personal accounts and production systems, and only test applications you are authorized to test. Common tooling includes a mobile security framework such as MobSF for automated static and basic dynamic analysis, and instrumentation like Frida and Objection for runtime inspection and testing resilience controls. The environment is the same controlled setup used for any responsible assessment: your own app, your own device, isolated, with the tools to look at both the static package and the running behavior.
Data storage checks
Data storage is one of the most examined groups, and the rule is simple: no sensitive data should be stored insecurely, so your check is to look everywhere the app writes and confirm nothing sensitive sits in plaintext. Examine the app's private storage, its shared preferences, its databases, any files it creates, its logs, and the clipboard and any external storage it touches, looking for credentials, tokens, personal data, or keys stored in the clear. Do this both statically, by reviewing how the code writes data, and dynamically, by inspecting the actual files the app produces at runtime.
The checks that most often find problems are logs and preferences. Sensitive values written to logs are a frequent finding, since debug logging tends to leak tokens and personal data, and shared preferences or plaintext files holding credentials are common in apps that skipped secure storage. Confirm that sensitive data is either not stored on the device or is protected using the platform's secure mechanisms, with keys in hardware-backed storage. Also check that the app is not backed up in a way that exposes sensitive data. A clean storage result means an inspection of every place the app writes turns up nothing sensitive in the clear.
Cryptography checks
Cryptography is the other group auditors focus on, and the checks cover both the algorithms used and how keys are handled. On algorithms, confirm the app uses strong, current, standard cryptography and avoids weak or broken choices: no ECB mode, no outdated ciphers like DES or RC4, no MD5 or SHA-1 for security purposes, and authenticated encryption such as AES-GCM where confidentiality and integrity are needed. You find these by reviewing the cryptographic calls in the decompiled code and flagging any weak algorithm or mode.
On keys, confirm they are managed safely: not hardcoded in the app, generated with a secure random source, and, for sensitive keys, stored in hardware-backed key storage rather than in software. A hardcoded key or an insecure random source undermines otherwise-strong cryptography, so these are as important as the algorithm choice. Check that the app does not roll its own cryptography where a standard primitive exists, since custom crypto is a common source of weakness. A clean cryptography result means strong standard algorithms used correctly, with keys that are neither weak, hardcoded, nor exposed.
Testing the other control groups
The remaining groups round out the checklist, each with its own focus. For authentication, confirm identity and authorization are enforced on the server rather than trusted from the client, and that sessions and tokens are handled securely. For network, intercept the app's traffic on your own test device to confirm strong transport security and, where used, certificate pinning, and that no sensitive data travels in cleartext. For platform, review the manifest and code for over-broad permissions, unsafely exported components, insecure inter-app communication, and any web components that mishandle input.
For code, check that inputs are validated, dependencies are current and free of known vulnerabilities, and unsafe patterns are absent. For resilience, on a rooted device, attempt to bypass the app's anti-tampering and root detection to see whether they hold, remembering these are defense-in-depth rather than a boundary. For privacy, confirm the app collects only the data it needs, discloses it accurately, and honors consent. Each group is tested the same way in principle: apply the MASTG checks, record a result with evidence, and note what needs fixing.
Static versus dynamic testing
A thorough MASVS audit uses static and dynamic testing together, because each finds what the other misses. Static analysis, examining the decompiled app, is where you find hardcoded secrets, weak cryptographic calls, over-broad permissions in the manifest, and insecure code patterns, since these are visible in the package without running it. It is fast and broad, and it is what an automated scanner does well, giving you a wide first pass over the build.
Dynamic analysis, running the app and observing it, is where you find how the app actually behaves: what it writes to storage at runtime, what its network traffic looks like, how it handles a manipulated request, and whether its resilience controls can be bypassed. Some findings only appear at runtime, so dynamic testing catches what static review cannot infer. The two are complementary, and a real audit combines them: static analysis to survey the build quickly and dynamic analysis to confirm behavior and probe the controls that only reveal themselves when the app is running.
MASVS testing at a glance
Mapping each control group to what and how you test focuses the audit. The table below summarizes it.
| Control group | What to test | How |
|---|---|---|
| MASVS-STORAGE | No sensitive data in insecure storage | Inspect files, preferences, logs, static and dynamic |
| MASVS-CRYPTO | Strong algorithms, safe key handling | Review crypto calls; no weak modes or hardcoded keys |
| MASVS-AUTH | Server-enforced authentication and authorization | Test the API and session handling |
| MASVS-NETWORK | Secure transport, no cleartext | Intercept traffic on a device you own |
| MASVS-PLATFORM | Permissions, IPC, and web components | Review the manifest and exported components |
| MASVS-RESILIENCE | Anti-tampering as defense in depth | Attempt bypasses on a rooted device |
Read the table as the audit spine: the storage and cryptography rows are where audits spend the most time and find the most.
Audit checklist
Working through these steps runs a MASVS audit end to end. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Set up the environment | Own device, rooted for resilience, plus tooling | [ ] |
| Run static analysis | Decompile and review storage, crypto, and manifest | [ ] |
| Run dynamic analysis | Observe runtime storage, traffic, and behavior | [ ] |
| Check data storage | No sensitive data in the clear anywhere it writes | [ ] |
| Check cryptography | Strong algorithms, keys not weak or hardcoded | [ ] |
| Map and remediate | Tie findings to control groups, fix by severity | [ ] |
The step that structures the whole audit is mapping findings to control groups, because it turns a list of issues into a clear picture of which MASVS areas pass and which need work.
Automate part of the audit
Because static analysis is broad and repeatable, automating it gives your audit a fast, consistent first pass over the build before the manual dynamic testing, and it is the part most easily standardized across apps.
A scanner like PTKD.com analyzes your build and reports issues such as insecure data storage, weak cryptography, leaked keys, over-broad permissions, and weak binary protections by severity, mapped to OWASP MASVS control groups, covering much of the storage, cryptography, platform, and resilience static checks automatically. To be clear about the boundary: PTKD covers what is analyzable from the build and does not replace the dynamic and manual MASTG tests, such as intercepting live traffic or verifying server-side authorization. It gives you the static, MASVS-mapped portion of the checklist quickly so your manual effort goes to the runtime and server checks.
What to take away
- A MASVS testing checklist verifies an app against the eight control groups, using the MASTG for the concrete test cases and combining static and dynamic analysis.
- Test on your own build and device, kept isolated, with a rooted device for the resilience checks, and only test apps you are authorized to test.
- For data storage, confirm no sensitive data sits in preferences, files, databases, or logs in the clear, and that keys use hardware-backed storage.
- For cryptography, confirm strong, standard algorithms with no weak modes, and keys that are not hardcoded, weak, or generated with an insecure random source.
- Map every finding to a control group, remediate by severity, and automate the static portion with a MASVS-mapped scanner like PTKD.com.
