OWASP Mobile Top 10 Guide: Risks and Controls for Mobile Apps

Every mobile app ships its code, configuration and often its secrets to devices the publisher does not control, and the OWASP Mobile Top 10 names the ten ways that most often goes wrong. The 2024 final release reordered the list around credentials, supply chain and authorisation, and it is the reference most security teams, auditors and app store reviewers now use when they talk about mobile risk. This guide explains each of the ten risks in practical terms, maps them to the OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide (MASTG), and gives a rollout plan, metrics and failure patterns. It is written for application security engineers, mobile developers and architects, and for anyone setting mobile security requirements for an in-house or outsourced app. For general mobile app architecture see the Mobile App Security Guide; for test methods see the Mobile App Security Testing Guide.

Key takeaways

• Credentials lead the 2024 list. M1 Improper Credential Usage covers hard-coded API keys, credentials sent or stored insecurely, and keys that cannot be rotated. Anything in the app package should be treated as public.
• The server is the security boundary. M3, M4 and M7 all come back to the same rule: client-side checks can be bypassed on a rooted or jailbroken device, so authentication, authorisation and licensing decisions belong on the backend.
• The Top 10 is an awareness list, MASVS is the standard. Use the Top 10 to prioritise and communicate; use MASVS controls as requirements and MASTG tests as evidence.
• Platform defaults do a lot of the work if you leave them on. Android blocks cleartext traffic by default for apps targeting API 28 and higher, and platform key stores exist for secrets. Most findings come from switching defaults off.
• Resilience is a cost multiplier, not a fix. Obfuscation and integrity checks (M7) slow attackers down, but they do not replace secure design, and MASVS states that their absence is not in itself a vulnerability.

The OWASP Mobile Top 10 2024 at a glance

OWASP published the 2024 list as a final release on the project page, replacing the 2016 edition. The table summarises each entry from its OWASP risk page and the MASVS control groups that address it. The MASVS mapping is our own, based on the control group descriptions in MASVS.

Credentials, supply chain and authorisation (M1 to M3)

M1 Improper Credential Usage

OWASP rates this risk easy to exploit and common, with severe impact, and names automated tools that search app packages for hard-coded credentials as the main threat agent. The iOS apps hard-coded secrets research shows the scale: Cybernews reported that 71% of 156,080 App Store apps it analysed contained at least one hard-coded secret, including cloud storage bucket details and Stripe secret keys.

• Never ship a secret that grants backend access: put privileged calls behind your own API, and have the backend hold provider keys in a vault. See the Secrets Management Guide.
• Use revocable, per-device tokens: OWASP recommends secure, revocable access tokens over storing user credentials on the device, plus regular rotation of API keys and tokens.
• Restrict keys that must be embedded: some client keys (mapping, analytics, push) are designed to be public; restrict them by app signature, bundle ID and API scope in the provider console, and monitor their usage. See the API Key Management Guide.
• Scan builds, not only source: secrets also arrive through build variables and SDK config files, so scan the compiled APK, AAB or IPA in CI. See the Secrets Scanning Buyer's Guide.

M2 Inadequate Supply Chain Security

OWASP lists vulnerable third-party components, insecure app signing and distribution, and code inserted during the build as the main weaknesses, and rates detectability as difficult. The example scenario is malware injected during development and signed with a valid certificate so that it passes store review.

• Inventory SDKs: keep a software bill of materials for every release, including advertising, analytics and crash-reporting SDKs that run with the app's permissions.
• Protect signing keys: keep upload and signing keys out of developer laptops, in a managed signing service or HSM, with named owners. The signing key is a non-human credential with the power to publish code to every user.
• Harden the build pipeline: pinned dependencies, reviewed CI changes and short-lived pipeline credentials. See the Software Supply Chain Security Guide and the CI/CD Security Guide.

M3 Insecure Authentication/Authorization

The M3 page lists the patterns testers find most: backends that accept API calls without an access token, passwords kept on the device for "remember me", four-digit PINs as the only secret, roles sent from the app and trusted by the server, and IDOR where the server checks the bearer token but not whether the account ID in the URL belongs to it.

• Authenticate on the server: load app data only after server-side authentication succeeds, and require at least as many factors as the web channel.
• Use biometrics to unlock a key, not as the check: OWASP recommends Face ID or Touch ID to release a biometric-protected secret such as a session token, rather than as a yes or no that the app trusts. This aligns with MASVS-AUTH-2 on local authentication.
• Authorise every object: the backend derives the user and role from the token, never from request parameters or headers. The Top 10 API Security Risks covers the server half of this problem.
• Use standard protocols: OAuth 2.0 with PKCE through the system browser for user sign-in, and short-lived access tokens with refresh token rotation. See the Token and Session Security Guide.

Data handling and communication (M4 to M6, M9, M10)

These five risks are about data at the edges of the app: what comes in, what goes over the network, and what stays on the device.

• M4 Input/Output Validation: validate input by context (file paths, SQL, deep links, intent extras), use parameterised queries in local SQLite, and encode output rendered in WebViews. Treat data from other apps through IPC as untrusted (MASVS-PLATFORM-1).
• M5 Insecure Communication: OWASP's first instruction is to assume the network layer is not secure. Encrypt every channel, require full chain and hostname verification, and never ship code that accepts all certificates. On Android, remove allow-all hostname verifiers and never override onReceivedSslError to proceed; on iOS, remove calls such as setAllowsAnyHTTPSCertificate.
• M6 Privacy Controls: minimise PII (coarse rather than precise location, less frequent updates), keep it out of logs, URLs and crash reports, and configure backup inclusion explicitly. OWASP notes that Android's hasFragileUserData setting can let data survive uninstallation.
• M9 Insecure Data Storage: store tokens and keys in the iOS Keychain or Android Keystore, not in SharedPreferences, plists or SQLite in plain text. Check caches, logs and temporary files, which the M9 page lists as common leak points.
• M10 Insufficient Cryptography: use platform or well-established libraries, current algorithms and key lengths, hardware-backed key storage, and salted password hashing with PBKDF2, bcrypt or scrypt. Do not allow fallback to weak algorithms, which enables downgrade attacks.

Android network security configuration reference

Android's Network Security Configuration file (res/xml/network_security_config.xml, referenced by android:networkSecurityConfig in the manifest) is where most M5 and M8 network findings are fixed or introduced.

On iOS the equivalent control is App Transport Security; the usual finding is NSAllowsArbitraryLoads set to true in Info.plist rather than a narrow, documented exception for one domain.

Binary protection and misconfiguration (M7 and M8)

OWASP's M7 page is clear that all apps are exposed to binary attacks, because binaries are easy to obtain from stores or devices, and that apps holding hard-coded secrets, valuable algorithms or AI models are at most risk. Its example scenarios are a hard-coded commercial API key extracted and resold, a licence check patched to always succeed, and an embedded AI model stolen.

• Threat-model first: decide what in the binary would cause financial or safety harm if extracted or modified. Apply MASVS-RESILIENCE controls (platform integrity, anti-tampering, anti-static and anti-dynamic analysis) only where that analysis justifies them.
• Back integrity checks with server attestation: local root or jailbreak detection can be found and patched out. Platform attestation (Google Play Integrity API, Apple App Attest) moves the decision to your server, though the MASVS resilience text warns that relying on them can lock out users of other Android flavours.
• Look at your own app as an attacker would: OWASP suggests inspecting binaries with tools such as MobSF, apktool, otool or Ghidra.

M8 is the risk most often found by automated scanning, because the settings live in the manifest and Info.plist:

• Debuggable release builds: android:debuggable must be false in release; app stores reject debuggable builds, but internal and enterprise distribution may not.
• Exported components: export only activities, services, receivers and content providers that must be reachable by other apps, set android:exported explicitly, and protect the rest with permissions. OWASP's example is a file provider that exposes the app's root path.
• Backup: OWASP recommends disabling backup mode on Android (android:allowBackup) or defining explicit backup rules so tokens and databases are not copied off the device.
• Permissions: request only what the core function needs; OWASP's example is a flashlight app asking for contacts, location and camera.

Where identity fits

Mobile apps are a large source of non-human credentials outside the control of the security team: API keys for maps, AI and payment providers, cloud storage keys, Firebase configuration, push service credentials and app signing keys. OWASP's own M7 page notes that leaked secrets must be rotated across the whole system, which is hard when they are hard-coded and every installed copy holds the old value. Treat each of these as a managed non-human identity with an owner, a scope and a rotation path that does not require users to update. The pattern maps to NHI2:2025 Secret Leakage in the OWASP Non-Human Identities Top 10. See the Top 10 NHI Risks and the Google API Keys Exposure 2026 case, where keys designed to be public in Maps and Firebase clients became sensitive once Gemini was enabled on the same project.

Choosing controls by app risk

Not every app needs every control. MASVS separates baseline security from resilience, and MASTG organises tests by the same control groups, so the decision is which groups to require and how deeply to test.

• Small teams: start with an automated scanner in CI, the Android and iOS secure defaults, and a backend that enforces authorisation. That covers most of M1, M3, M5, M8 and M9.
• Large portfolios: set MASVS controls as contract requirements for agencies and SDK suppliers, and require MASTG test evidence before store submission. See the Application Security Testing Buyer's Guide.

Implementing a Mobile Top 10 programme

1. Inventory apps and their backends: list every published app, internal app and white-labelled build, with its owner, distribution channel, SDKs and the APIs it calls.
2. Baseline with automated scanning: run a static and dynamic scan of the latest release binaries, not only source, and record findings against M1 to M10. Start in report-only mode in CI so teams can triage false positives without blocked releases.
3. Fix credentials first: move backend secrets out of the app, rotate every key found in a shipped binary (assume it has been extracted), and restrict keys that must remain client-side.
4. Enforce on the server: review each API the app calls for missing tokens, object-level authorisation and trust in client-supplied roles.
5. Lock platform defaults: add release-build checks that fail on debuggable, cleartext permitted, user CAs trusted, unexpected exported components and arbitrary loads in ATS.
6. Add manual MASTG testing: for apps with personal or financial data, test against the MASVS controls chosen for that profile before major releases.
7. Turn on blocking gates gradually: start with high-confidence rules (hard-coded secrets, debuggable, cleartext) as blocking, then add others once false positive rates are known.
8. Plan for rollback: keep the last known good build ready for staged rollout halt; for pinning, ship backup pins and a server-side kill switch or remote configuration so a broken pin set does not lock users out. Use staged rollouts on Google Play and phased releases on the App Store to limit blast radius.

Detection and measurement

Mobile apps run on devices you cannot instrument, so most detection happens at the backend and in the build.

• Backend signals: API calls without valid attestation, unusual volumes from one client key, requests from outdated app versions, and authorisation failures that suggest object ID enumeration.
• Key usage: provider dashboards for embedded keys (maps, AI, payments), with alerts on cost or volume spikes, which is how an extracted key usually first shows up.
• Store and web monitoring: repackaged copies of your app in third-party stores, and your package or bundle ID in leaked-secret and paste feeds.
• Build telemetry: scanner results per release, kept as evidence for audits.

Framework mapping

Common failure patterns

• Hard-coded provider keys "because the app needs them": payment, storage and AI keys ship in the package and are extracted within days. The iOS apps hard-coded secrets study found Stripe secret keys and open storage buckets this way.
• Authorisation hidden in the UI: admin features are hidden in the app but the API never checks the role, which is OWASP's M3 "interface reliance" scenario.
• Certificate validation disabled for testing and never re-enabled: an allow-all trust manager written for a staging server reaches production. Use debug-overrides or a development CA instead, as OWASP's M5 page advises.
• Pinning without a backup pin or update path: a certificate change breaks every installed copy, and the emergency fix is to remove pinning entirely.
• Relying on root detection as authentication: local checks are patched out, and the backend trusts any client that reports itself as clean.
• Tokens and PII in logs and crash reports: sensitive values reach third-party crash-reporting services and device logs, which OWASP lists under both M6 and M9.

Practitioner checklist

• Map every app's findings to M1 to M10 and require MASVS controls by app risk profile.
• Scan release binaries (APK, AAB, IPA) for secrets in CI and rotate anything found in a shipped build.
• Keep backend credentials server-side; restrict any client key by app signature, bundle ID and API scope.
• Enforce authentication and object-level authorisation on every API the app calls.
• Fail release builds that are debuggable, permit cleartext, trust user CAs or allow arbitrary loads.
• Store tokens and keys only in the Keychain or Keystore, and exclude them from backups.
• Pin only endpoints you control, with backup pins and a remote way to recover.
• Inventory SDKs per release and protect signing keys as privileged non-human credentials.
• Run MASTG-based manual tests before major releases of apps holding personal or financial data.

Standards and references

• OWASP: Mobile Top 10 project
• OWASP: Mobile Top 10 2024 Final Release risk list
• OWASP: Mobile Application Security Verification Standard
• OWASP: Mobile Application Security Testing Guide
• Android Developers: Network security configuration
• OWASP: NHI2:2025 Secret Leakage
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Stored Application Data

Related NHI Mgmt Group resources: Mobile App Security Guide · Mobile App Security Testing Guide · OWASP Top 10 Guide · Mobile Threat Defense Buyer's Guide · API Key Management Guide