A Mobile App Security Checklist Built on OWASP MASVS

MASVS, MASTG and the Mobile Top 10: how they fit together

The MASVS defines what a secure mobile app should do, grouped into control areas. The Mobile Application Security Testing Guide (MASTG) explains how to verify each control on iOS and Android. The OWASP Mobile Top 10 is a risk awareness list that ranks the most common categories of failure. Use the Top 10 to explain priorities to stakeholders and MASVS to define acceptance criteria for your team.

The mapping is approximate; several risks touch more than one control group. It is a planning aid, not an official OWASP crosswalk.

STORAGE and CRYPTO: protecting data on the device

Start by listing every piece of sensitive data the app stores: tokens, personal data, health or financial records, cached files. Then decide whether each item needs to be stored at all. Data you never write to disk cannot leak from it.

• iOS: store credentials and tokens in the Keychain with an appropriate accessibility class (for example, available only when unlocked and not migrated to other devices where that fits). Use Data Protection classes for sensitive files.
• Android: generate and hold keys in the Android Keystore, ideally hardware-backed, and use them to encrypt sensitive data you store. Avoid storing tokens in plain SharedPreferences.
• Cross-platform: in Flutter and React Native, use well-maintained plugins that wrap Keychain and Keystore rather than JavaScript or Dart-only storage.
• Exclude sensitive data from logs, screenshots in the app switcher, clipboard and backups where appropriate.
• Use platform crypto APIs and current algorithms. Never write custom cryptography or hardcode encryption keys.

AUTH and NETWORK: sessions, TLS and pinning trade-offs

Authentication and authorization decisions belong on the server. The app can hide a button, but the API must reject a request the user is not allowed to make. Use short-lived access tokens with refresh tokens, standard flows such as OAuth 2.0 with PKCE for third-party sign-in, and platform biometrics to unlock locally stored credentials rather than as a replacement for server-side auth.

All traffic should use TLS. Keep App Transport Security on iOS and Android's network security configuration strict, with no cleartext exceptions in release builds.

Certificate pinning: when it is worth it

Pinning makes the app trust only specific certificates or public keys, which raises the bar for interception. It also creates an outage risk: if your certificate changes and the app does not have the new pin, users lose connectivity until they update. If you pin, pin public keys rather than leaf certificates, include backup pins, coordinate certificate rotation with releases and consider a remote kill switch. For many consumer apps, strict TLS without pinning is a reasonable choice; for banking, health and high-value targets, pinning is usually worth the operational cost.

PLATFORM and CODE: secrets, inputs and dependencies

Anything compiled into the app can be extracted with freely available tools. Obfuscation slows attackers down but does not hide a secret. API keys for paid services, database credentials and signing keys should live on your backend, with the app calling your server, which then calls the third party.

• Keep secrets out of source control and the binary; use a secrets manager in CI.
• Validate deep links, intents, URL schemes and WebView inputs; never trust data from other apps.
• Restrict exported Android components and limit WebView JavaScript bridges.
• Run software composition analysis on every build to catch vulnerable libraries and SDKs.
• Pin dependency versions, review new SDKs before adding them, and remove unused ones.
• Strip debug logging and test endpoints from release builds.

RESILIENCE and PRIVACY: hardening and data minimization

Resilience controls, such as root and jailbreak detection, tamper checks, obfuscation and runtime integrity APIs like Apple's App Attest and Google's Play Integrity API, make reverse engineering and automated abuse harder. They are defense in depth, not a substitute for server-side checks. Apply them in proportion to risk: a payments app needs more than a recipe app.

MASVS-PRIVACY focuses on collecting only what you need, being transparent about it and giving users control. In practice that means minimizing permissions, avoiding device identifiers you do not need, keeping App Store privacy labels and Google Play data safety answers accurate, and honoring deletion requests. Teams building healthcare apps or fintech products should map these controls to their regulatory obligations with their compliance advisers.

Testing with the MASTG and building security into delivery

1. 1

   Pick your verification level

   Agree which MASVS controls apply, and whether resilience controls are in scope, based on the data and threat model.

2. 2

   Automate the basics

   Add static analysis, dependency scanning and secret detection to CI so every pull request is checked.

3. 3

   Review high-risk changes

   Require a security-aware reviewer for authentication, payments, storage and networking code.

4. 4

   Test against the MASTG

   Before major releases, have an internal or independent tester work through the relevant MASTG test cases on real devices.

5. 5

   Track and retest

   Log findings with severity, fix them, and retest. Repeat after significant architecture or SDK changes.

Security does not end at launch. New OS versions, SDK updates and disclosed vulnerabilities all require follow-up, which is why we fold dependency updates and periodic retesting into ongoing app maintenance. For larger organizations, our enterprise mobile development work adds MDM, SSO and audit requirements on top of this baseline.