Mobile App Security Checklist Based on OWASP MASVS

What MASVS is and how to use it

OWASP MASVS (Mobile Application Security Verification Standard) is an open standard of security requirements for mobile apps. It comes with the MASTG, a guide with testing techniques. The standard does not tell you how to write code; it defines what must be verified.

MASVS categories:

Not every app needs every requirement. A banking or health app needs resilience against reverse engineering; a product catalog usually does not. Define a threat model first, then choose how deep to go.

Data storage (STORAGE, CRYPTO)

• Tokens and keys live only in the Keychain (iOS) and Android Keystore / EncryptedSharedPreferences, never in UserDefaults, SharedPreferences or plain files.
• Logs contain no tokens, passwords, card numbers or personal data, including in release builds.
• Caches, app switcher snapshots and the clipboard do not expose sensitive screens.
• Backups do not carry secrets out: check Android backup settings and file protection attributes on iOS.
• No homemade cryptography and no hardcoded keys; standard platform APIs only.

Network and certificate pinning (NETWORK)

• All traffic uses TLS; ATS on iOS and Network Security Config on Android have no "allow everything" exceptions.
• The app rejects self-signed or invalid certificates. Make sure debug code did not ship.
• Certificate pinning is for high-risk apps. Pin the public key, keep a backup pin and plan rotation: a pinning mistake can lock every user out of the server until an update ships.

<network-security-config>
  <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Authentication (AUTH)

• The server makes access decisions, not the app. A hidden button is not protection.
• Access tokens are short-lived, refresh tokens can be revoked, and logout invalidates the session server-side.
• Biometrics unlock a key in secure storage rather than flipping a boolean "user passed Face ID".
• Sensitive operations (changing phone number, withdrawing funds) require re-confirmation.

Platform and code (PLATFORM, CODE)

• Deep links and intents validate input and never open internal screens without auth.
• Exported Android components are kept to a minimum; WebViews do not load arbitrary URLs or expose unnecessary JS bridges.
• The app requests only the permissions it needs.
• Dependencies are updated, known vulnerabilities are tracked, and there is a forced update mechanism.

Reverse engineering and tampering (RESILIENCE)

Any client app can be taken apart. The goal is not to make that impossible but to raise the cost of attack for genuinely valuable data:

• obfuscation (R8, Dart obfuscation, native tooling);
• root/jailbreak, debugger and hook detection, treated as a signal rather than the only defense;
• integrity checks via Play Integrity API and App Attest, verified on the server;
• secrets that must not leak are never stored in the app at all.

A basic pre-release review

1. Define the threat model and the level of requirements.
2. Walk through the checklist above together with the developers.
3. Run static analysis (for example, MobSF) on the release build.
4. Inspect traffic through a proxy on a test device.
5. Review the app sandbox contents after a typical user flow.
6. Record findings, prioritize them and fix critical ones before release.