Before shipping a mobile release, check eight things: data storage, crypto and keys, authentication, network settings, platform interaction, code and dependencies, resilience choices and privacy. This checklist follows the OWASP MASVS groups and fits on one page, so you can run it every release.
Storage and leaks
- Is sensitive data kept in app private storage, with secrets in the platform keystore (Keychain on iOS, Keystore on Android)?
- Are backups disabled or restricted for sensitive files?
- Do logs in the release build avoid tokens and personal data?
- Do caches and the app switcher preview avoid sensitive screens?
- Is there less data on the device than last release, or the same? If more, why?
See where apps leak data.
Crypto and keys
- Platform crypto APIs, not custom algorithms.
- No hardcoded keys or credentials in the binary.
- Keys bound to hardware where the platform supports it.
Authentication
- Server enforces authentication and authorization on every request.
- Tokens are short lived, revocable and device specific. No passwords stored.
- Local biometric checks use the platform API with a fallback path.
- Sensitive actions need re-authentication.
Network
- HTTPS everywhere. Certificate validation is never disabled, even in test code that could ship.
- On Android, the network security config has no unscoped cleartext or extra trust anchors. On iOS, App Transport Security exceptions are justified. Check Apple's current App Transport Security documentation for the exact rules.
- If you pin, backup pins and a rotation plan exist.
Platform interaction
- Deep links and other entry points validate their input and require authentication before showing sensitive screens.
- WebViews are configured securely and expose no unneeded JavaScript bridges to native code.
- Sensitive fields are masked and excluded from auto-generated screenshots.
Code and dependencies
- The SBOM for this build is generated and scanned. Known vulnerable components are fixed or have a recorded decision.
- Debugging is disabled in the release build.
- Inputs from the UI, IPC, network and file system are validated.
- A minimum app version gate works and has been tested.
Resilience
- A written decision on root or jailbreak response, obfuscation and tamper detection, based on how much tampering would cost you.
- Integrity signals are sent to the server where it makes sense.
Privacy
- Every SDK is on the list with an owner and purpose.
- No SDK talks to third parties before consent is confirmed.
- Store data declarations match real traffic.
- Users can manage and delete data and withdraw consent.
How to run it
Give each item an owner and a status: pass, fail or not applicable. A failed item is a ticket, not a note. Keep the completed list with the release record. If a buyer asks how you secure your app, this is the evidence.
Do not turn the list into a gate that nobody understands. Start with the items that have caused you problems before and grow it as the team learns.
Quick check
How long should this take?
Once the team has the habit and some automation for scans and traffic checks, much of it is a review of recorded results. Expect longer the first time.
Do I need a penetration test as well?
The OWASP cheat sheet recommends penetration testing for mobile apps, including crypto reviews. A checklist does not replace it.
Sources
- OWASP Mobile Application Security Cheat Sheet
- MASVS control definitions, for example STORAGE-2
- Android network security configuration
Last reviewed: 19 October 2026.
