Most mobile breaches aren't exotic exploits. They're secrets shipped in the binary, tokens in the wrong storage, and APIs that trust the app too much.
Mobile security has a canonical playbook: OWASP’s MASVS (the verification standard) and its companion testing guide define what a secure app looks like across storage, cryptography, authentication, network, and platform interaction. You don’t need to read the standard cover to cover — you need to close the handful of gaps that cause most real incidents. This checklist is that shortlist, in the order attackers actually exploit it.
Sensitive data belongs in the platform keystore — iOS Keychain, Android Keystore — never in SharedPreferences, plists, or files, and never logged. Auth tokens should be short-lived with rotating refresh tokens, revocable server-side the moment a device is reported lost. Biometric unlock should gate access to the keystore entry, not replace server-side authentication.
Assume the binary is public. Anything shipped in the app — API keys, endpoints, feature flags — will be extracted within hours of release, so real secrets stay server-side and the app gets only scoped, expiring credentials. Obfuscation (R8/ProGuard) raises the effort but is not protection; certificate pinning helps against interception but must ship with a rotation plan so a certificate change doesn’t brick the app.
TLS everywhere is table stakes; the real work is the API behind the app. Every request must be authorized server-side — object-level checks on every resource, not “the app wouldn’t ask for someone else’s data”. Broken object-level authorization remains the top API vulnerability in practice, and mobile APIs are the most common place it’s found, because teams trust their own client.
Rate-limit authentication and expensive endpoints, validate all input server-side, and treat the mobile API with the same rigor as a public one — because it is one. Add device-integrity signals (Play Integrity, App Attest) for high-risk actions, keep dependencies patched with automated scanning in CI, and make security testing part of the release train rather than a pre-launch event.
Move all tokens and sensitive data into Keychain/Keystore; audit logs for leakage.
Strip real secrets from the binary — server-side proxies and scoped credentials instead.
Enforce object-level authorization on every API endpoint the app calls.
Short-lived tokens with rotation and server-side revocation.
Certificate pinning with a rotation plan; TLS config verified, no cleartext fallbacks.
Dependency scanning in CI, and a MASVS-based pen test before major releases.
Yes for high-value apps — it blocks man-in-the-middle interception even on compromised networks — but only with a key-rotation strategy (pin backup keys, or pin to an intermediate CA). Pinning without a plan turns routine certificate changes into outages.
For most apps, detect and degrade: flag high-risk actions rather than block outright. For banking-grade threat models, integrity APIs (Play Integrity, App Attest) plus server-side risk scoring are the standard approach. Never treat client-side detection as your only control.
A full MASVS-based test before launch and after major architectural changes, with automated dependency and static scanning on every build in between. Annual re-tests are the floor for apps handling money or health data.
The principles apply to both, but specifics differ — Android's more open install model raises the bar on tamper detection, while iOS puts more weight on Keychain and App Transport Security configuration.
API-side authorization checks — teams harden the client but assume the backend can trust any request that includes a valid token, which is exactly what attackers exploit.
A practical comparison of React Native and Flutter for cross-platform mobile development — performance, team fit, ecosystem, and when native beats both.
Read the guideProgressive web apps have closed much of the gap with native — but not all of it. Where each wins on iOS and Android, and how to choose for your product.
Read the guide