Web app security has had two decades of intense scrutiny. Mobile app security, by contrast, gets a fraction of the attention despite running on devices that hold biometric data, location history, payment tokens, and the complete contents of users private messaging. The OWASP Mobile Top 10 exists precisely because mobile-specific failure modes are different enough from web that direct translation does not work.
Why Mobile Is Different
Three structural differences shape how mobile threat models work. First, the client device is fundamentally untrusted — anyone with physical access can attempt reverse engineering, debugging, or instrumented analysis. Second, sensitive data is often cached locally for offline use, creating exposure web applications never face. Third, the integration with platform features (biometrics, secure enclave, push notifications, deep links) opens attack surfaces that have no web equivalent.
Improper Credential Usage and Insecure Storage
These two consistently lead the list because the failure modes are pervasive and the consequences are severe. Hardcoded API keys in compiled binaries, OAuth tokens cached in plaintext, biometric data stored outside the platform secure store, sensitive data persisted to logs that survive app restart. The defences are platform-specific (iOS Keychain, Android Keystore, encrypted SharedPreferences with proper configuration) and require deliberate use, not the platform default.
Insufficient Input/Output Validation
Mobile apps tend to trust their backend more than they should and trust user input less than they should — usually with the protections in the wrong place. Backend responses can be tampered with by a malicious proxy. User input that goes directly into a deep link, intent, or universal link can trigger unintended app behaviour. Input validation should run on the client (UX) and server (security); output validation should treat backend responses as untrusted just as carefully as user input.
Certificate pinning is a contested defensive control on mobile. Implemented correctly, it makes credential theft via compromised CAs much harder. Implemented incorrectly, it leads to apps that stop working when certificates rotate and engineers who disable pinning under pressure. If you pin, plan rotation and have a remote kill switch. If you cannot commit to that operational discipline, the platform-default certificate validation is acceptable for most apps.
Inadequate Privacy Controls
Mobile apps trip privacy regulators more than web apps because they request and receive richer data. Location, contacts, microphone, camera, motion sensors. The 2025 edition emphasises consent quality, data minimisation, and the lifecycle of permission state. An app that asks for camera access during onboarding and never asks again — even after a six-month gap in usage — is operating outside what most modern privacy regulators consider acceptable practice.
Common Misconfigurations the Top 10 Calls Out
- Debug builds reaching production stores — debug logs and developer endpoints exposed
- Cleartext network communication enabled for legacy reasons and never re-enabled
- Implicit intents (Android) used for sensitive flows, allowing other apps to intercept
- WebView configurations that grant JavaScript access to native bridges without origin restrictions
- Universal links and deep links not validated, allowing arbitrary callers to drive app state
- Backups and accessibility services enabled by default, exposing app data to other apps
How to Build a Mobile Security Programme
The minimum viable mobile security programme is: dependency scanning at build time, static analysis for common mobile patterns, dynamic testing on instrumented devices, and a periodic external review for the high-impact apps. The mobile-specific tooling has matured significantly in recent years. The remaining gap is mostly cultural — mobile development teams often have less direct exposure to security peer review than backend teams. Build the feedback loop deliberately.