Mobile app security checklist: OWASP MASVS-aligned guide
Contents
A mobile security checklist that only lists 'use encryption' isn't a checklist, it's a wish list. Engineering leaders auditing an app pre-release need itemized, testable controls mapped to OWASP MASVS levels, not device-hygiene tips aimed at consumers.
Most gaps we find in client audits aren't exotic: plaintext tokens, unpinned certificates, missing root detection. This guide gives you the concrete checklist, the Android/iOS divergences, and the testing methods that validate each item before you ship.
Mobile app security checklist: The short answer
OWASP MASVS defines the baseline: Level 1 (L1) covers standard mobile app security hygiene, Level 2 (L2) adds resilience controls like anti-tampering and stricter data protection for apps handling regulated or sensitive data (OWASP MASVS & MASTG: Mobile Security Guide).
Most teams build to L1 and stop there, then get surprised during a pen test. In our work auditing client codebases, we consistently find the same gaps regardless of team size: hardcoded API keys, missing certificate pinning, and tokens stored in plaintext instead of the Android Keystore or iOS Keychain.
A working checklist needs five layers: encrypt data at rest, pin certificates, run static application security testing and dynamic application security testing in CI, gate biometric authentication behind hardware-backed storage, and detect jailbreak or root at runtime.
What belongs on a mobile app security checklist
A mobile app security checklist worth using is organized by attack surface, not by project phase. Below is the structure our AppSec team applies during audits, mapped to OWASP MASVS control groups.
For hands-on vulnerability testing, tools like DIVA and AndroBugs, covered in our guide to Android security analysis tools, help validate these controls in practice.
Code and build
- Static application security testing (SAST) on every merge, not just before release
- No hardcoded API keys or secrets in source or build configs
- Jailbreak and root detection with a defined response (block, degrade, or log)
Data protection
- Data at rest encryption via Android Keystore or iOS Keychain, never custom crypto
- Input validation on every client-supplied field, including deep links and push payloads
- Biometric authentication gating access to sensitive data, not just app launch
Network and API
- Certificate pinning with backup pins configured
- Rate limiting on authentication and data-fetch endpoints to blunt credential stuffing
- Dynamic application security testing (DAST) against the live API, not a mocked backend
Most checklists stop at build. Ours extends into runtime, which is where audits find the real gaps.
Authentication controls: Biometrics, sessions, OAuth
Biometric authentication should gate access to the app, not replace server-side session validation. Face ID or Android's BiometricPrompt confirms the user is present, but the backend still needs to verify the OAuth 2.0 token on every request. Treat biometrics as a local access layer sitting in front of a standard token flow, not a substitute for it.
Session token expiration is where we see the most drift between design and implementation. In our mobile app security audits, we consistently find refresh tokens configured to never expire, or access tokens with lifetimes measured in weeks instead of minutes.
Our recommended baseline: access tokens expire in 15 minutes or less, refresh tokens rotate on use, and OAuth 2.0 implementations enforce PKCE for public clients. Pair this with biometric re-authentication for sensitive actions, like payments or profile changes, rather than relying on a single login event to secure the entire session.
How to secure data at REST on mobile devices
Data at rest encryption ensures no sensitive data, tokens, cached API responses, user profiles, sits on the device in plaintext. Android Keystore and iOS Keychain are the correct places for keys and credentials; app-level storage like SharedPreferences or NSUserDefaults is not, no matter how convenient.
The two platforms use different trade-offs. Android Keystore backs keys with hardware-level isolation (StrongBox or TEE) but requires more boilerplate to enforce key invalidation on biometric changes. iOS Keychain integrates more cleanly with Secure Enclave and Face ID, but its default accessibility attributes are looser than most teams assume.
In our mobile app security audits, plaintext token storage and hardcoded API keys are the two most recurring findings across otherwise well-built codebases. OWASP MASVS-STORAGE requirements exist precisely because developers default to whatever storage API ships fastest.
Encrypt any data that leaves memory, set the strictest Keychain accessibility class your UX permits, and verify it with static application security testing before each release, not after an incident.
Securing data in transit: TLS and certificate pinning
TLS 1.3 alone stops passive eavesdropping, not a man-in-the-middle attack from a malicious proxy or a compromised CA in the device's trust store (RFC 9846 & hopr blog). Certificate pinning closes that gap by hardcoding which certificate or public key the app accepts, independent of the OS trust store.
In our mobile app security audits, missing or misconfigured certificate pinning is one of the most common findings, sitting alongside plaintext token storage and hardcoded API keys. OWASP MASVS-NETWORK (MASVS-6 in the current OWASP MASVS taxonomy) treats pinning as an L2 control, expected for apps handling sensitive data such as financial or health records, optional at L1.
Pinning has a real operational cost: it breaks the moment your backend rotates its TLS certificate, unless you ship backup pins ahead of the rotation. Public key pinning, pinning the key rather than the leaf certificate, survives most rotations and is what we recommend by default.
According to Verizon's 2025 Mobile Security Index, 85% of organizations now believe mobile device attacks are on the rise, reinforcing why transit-layer controls sit inside static application security testing and dynamic application security testing scope, not just code review.
Android vs iOS security checklist differences
Android Keystore and iOS Keychain solve the same problem, hardware-backed key storage, but they fail in different ways worth checking separately in any mobile security checklist.
On Android, build setUserAuthenticationRequired(true) on the KeyGenParameterSpec when generating a key, and pair it with setInvalidatedByBiometricEnrollment(true) so a newly enrolled fingerprint can't silently gain access to existing keys.
On iOS, the equivalent control is kSecAttrAccessControl with .biometryCurrentSet, applied when the Keychain item is created, not left at the default kSecAttrAccessibleWhenUnlocked. Teams often set these once during initial mobile app development and never read the platform's updated documentation again.
Jailbreak and root detection differ too, with various techniques used to identify compromised devices. Android root detection has to catch Magisk's hiding modules, while iOS jailbreak detection targets Cydia artifacts and sandbox escapes. Neither is bulletproof.
Treat detection as a signal for step-up authentication, not a gate.
In our audits, root and jailbreak checks are frequently built once and never revisited against new bypass tools published on GitHub. Zimperium's mobile threat research found that 33% of jailbroken devices it observed carried malware, and that rooted or jailbroken devices are roughly 250 times more likely to suffer a full system compromise than standard devices (Zimperium, mobile threat research).
Map both platforms against OWASP MASVS L2 resilience requirements, not just L1, since L1 alone misses many privacy and data-at-rest vulnerabilities that attackers actively exploit. The OWASP Mobile Application Security project also maintains test cases specific to each platform's applications, which are worth cross-checking against your own practices.
For Android, static and dynamic analysis tools like MobSF can help surface these gaps before attackers exploit them.
Protecting against reverse engineering and tampering
Code obfuscation raises the cost of reverse engineering; it does not stop a determined attacker with a decompiler and time. Treat it as a delay tactic, not a control. In our audits, we consistently find release builds shipped with obfuscation disabled or default ProGuard/R8 rules that strip nothing meaningful from Kotlin or Swift symbol tables.
Jailbreak and root detection catches the environment where tampering happens, not the tampering itself, and checks like this belong in OWASP MASVS resiliency requirements for MASVS-L2 apps handling regulated data.
The decision that matters: obfuscation is a build-time, low-cost baseline for every app; runtime application self-protection (anti-debugging, integrity checks, root/jailbreak detection with server-side revalidation) is reserved for L2-tier apps in finance, health, or payments, where a single tampering incident is expensive.
Validating the checklist: SAST, DAST, and pentesting
Static application security testing, dynamic application security testing, and software composition analysis catch different failure classes, so a mobile app security checklist needs all three, not one. SAST scans source or bytecode for hardcoded secrets and insecure crypto calls before a build ships. DAST exercises the running app and its API traffic, catching certificate pinning gaps or session handling flaws that static analysis misses.
Interactive testing (IAST) sits between the two, instrumenting the app during QA runs, useful when CI budget allows it.
Software composition analysis matters as much as either. In our audits, a large share of exploitable issues trace back to third-party SDKs, not first-party code, and SCA is the only method that flags a vulnerable ad or analytics library before release.
Map each method against OWASP MASTG test cases, then run a full pentest before submission to the App Store or Play Store, since both platforms now scrutinize permission and data-handling disclosures during review.
Hardening APIs, permissions, and compliance readiness
Mobile app security checklist work stops at the device unless backend API hardening gets equal attention. In our audits we consistently find rate limiting absent on authentication and token-refresh endpoints, leaving apps open to credential stuffing at scale, alongside input validation gaps that let malformed payloads reach business logic untested.
OWASP MASVS network and platform requirements (MASVS-NETWORK, MASVS-PLATFORM) map directly onto GDPR and HIPAA data-handling obligations, so treat permission scoping and least-privilege API keys as compliance controls, not just engineering hygiene.
Ownership needs a name attached: developers fix code-level findings, AppSec owns threat modeling and MASVS mapping, QA validates fixes through regression testing before App Store or Play Store submission, where reviewers increasingly flag missing rate limiting on sensitive data endpoints.
FAQ: Mobile app security checklist questions
What is the OWASP mobile security checklist?
How much does mobile app security testing cost?
What's the difference between certificate pinning and public key pinning?
Does this checklist cover GDPR and HIPAA compliance?
How often should a mobile app security audit be repeated?
Get your mobile app security checklist audited
Running through this checklist once does not make an app secure. In our audits, teams that pass OWASP MASVS L1 at launch drift out of compliance within two release cycles as certificate pinning configs go stale and new SDKs introduce fresh data handling risks.
A mobile app is only as secure as its weakest post-launch update, which is why ongoing security ownership matters as much as the initial build. If you need expert mobile app builders to establish secure foundations from day one, partnering with an experienced team can prevent many of these post-launch drift issues.
If your team needs consistent support across channels for patching, monitoring, and re-testing against OWASP without pulling engineers off product work, our Ops & Managed Services team runs 24/7 monitoring, proactive maintenance, and security audits to reduce your operational overhead.
