The OWASP Mobile Top 10 2024, Explained

Mobile apps run on devices you do not control, cache sensitive data locally, and talk to backends over untrusted networks. That combination creates risks a web app checklist never covers. The OWASP Mobile Top 10 is the reference list for those risks, and it is the backbone of any serious mobile application penetration test.

The current edition is the 2024 list, OWASP’s first major revision since 2016. It is still the current edition in 2026, so if you are working to “OWASP Mobile Top 10 2024,” you are working to the right one. This guide covers all ten risks, what changed from 2016, and how a tester actually checks your app against each.

Why mobile needs its own Top 10

On the web, your code runs on servers you control. On mobile, your code ships to an attacker’s phone, where it can be decompiled, instrumented, and tampered with at will. Add insecure local storage and the backend APIs every app depends on, and you get a distinct threat model. The web application OWASP Top 10 2025 was written for code on servers you control, not for an app on a device you do not, which is why mobile has always had a separate list.

What changed from 2016 to 2024

The 2024 list was rewritten rather than reshuffled. Three categories kept their exact names across both editions: Insecure Data Storage, Insecure Communication, and Insufficient Cryptography, although their ranks moved. Authentication and authorization, split into two entries in 2016, are now a single combined risk. Reverse engineering and code tampering, two separate 2016 entries, are now folded into one “binary protections” risk, and Security Misconfiguration rewords the old Extraneous Functionality entry. OWASP marks the remaining four as new: credential usage, supply-chain security (a modern app is largely assembled from third-party code), input/output validation, and privacy controls, which OWASP ties to data protection laws such as GDPR and CCPA. Two 2016 entries, Improper Platform Usage and Client Code Quality, have no direct counterpart in OWASP’s comparison.

2024 risk	Change from 2016, per OWASP
M1: Improper Credential Usage	New in 2024
M2: Inadequate Supply Chain Security	New in 2024
M3: Insecure Authentication/Authorization	Merges 2016 M4 (Insecure Authentication) and M6 (Insecure Authorization)
M4: Insufficient Input/Output Validation	New in 2024
M5: Insecure Communication	Same name, moved from M3
M6: Inadequate Privacy Controls	New in 2024
M7: Insufficient Binary Protections	Merges 2016 M8 (Code Tampering) and M9 (Reverse Engineering)
M8: Security Misconfiguration	Rewording of 2016 M10 (Extraneous Functionality)
M9: Insecure Data Storage	Same name, moved from M2
M10: Insufficient Cryptography	Same name, moved from M5

The ten risks, and how we test each

For every risk below, the example finding is the kind of thing a test turns up in a real build, and the tester check is how we confirm it. Each maps to a control group in the OWASP Mobile Application Security Verification Standard (MASVS), the companion standard our mobile testing is built around.

M1: Improper Credential Usage. Hardcoded credentials, insecure credential storage, and weak handling of API keys and tokens baked into the app.

• Example finding: an API key and a service-account password recoverable as plain strings inside the decompiled app.
• Tester check: static analysis of the binary for embedded secrets, and review of how the app obtains, stores, and rotates tokens (MASVS-STORAGE, MASVS-AUTH).

M2: Inadequate Supply Chain Security. Vulnerable or malicious third-party SDKs and libraries: a compromised dependency ships inside your app.

• Example finding: an analytics SDK several major versions behind, carrying a known vulnerability, bundled in the release build.
• Tester check: inventory the third-party components in the binary and cross-check their versions against known-vulnerability data (MASVS-CODE).

M3: Insecure Authentication/Authorization. Weak or bypassable authentication, and authorization decisions made on the client that an attacker can simply skip.

• Example finding: an “admin” flag enforced only in the app’s UI, so calling the backend directly exposes admin functions to a normal user.
• Tester check: dynamic testing of the login and session flow, then replaying and modifying backend calls to confirm the server, not the app, enforces access (MASVS-AUTH).

M4: Insufficient Input/Output Validation. Unvalidated data leading to injection, memory issues, or manipulation of app behavior.

• Example finding: a WebView that renders server-supplied HTML without sanitization, allowing script injection into the app context.
• Tester check: fuzzing inputs and inspecting how the app handles untrusted data from the network, deep links, and inter-process channels (MASVS-CODE, MASVS-PLATFORM).

M5: Insecure Communication. Weak or missing TLS, absent certificate pinning, and cleartext traffic that lets an attacker on the network intercept data.

• Example finding: the app accepts a proxy’s substituted certificate, so all its traffic is readable on a hostile Wi-Fi network.
• Tester check: intercept the app’s traffic on a test device to confirm TLS configuration, cleartext exposure, and whether pinning is present and enforced (MASVS-NETWORK).

M6: Inadequate Privacy Controls. Mishandling of personal data, over-collection, and leaking personal information through logs, backups, or third parties.

• Example finding: full device identifiers and location written to the app’s debug log and included in the platform backup.
• Tester check: trace what personal data the app collects, stores, logs, and shares with third-party SDKs against what it declares (MASVS-PRIVACY, MASVS-STORAGE).

M7: Insufficient Binary Protections. No obfuscation or anti-tampering, so an attacker can reverse-engineer the app, extract secrets, and repackage it. OWASP describes the two attacks this covers as reverse engineering (decompiling the binary for secrets and logic) and code tampering (modifying it to remove checks).

• Example finding: the app runs unmodified after being repackaged with a patched license check and re-signed.
• Tester check: attempt to decompile, instrument, and repackage the app, and test any root/jailbreak or tamper detection it claims (MASVS-RESILIENCE).

M8: Security Misconfiguration. Insecure default settings, debuggable builds shipped to production, over-permissive components, and unnecessary functionality left enabled.

• Example finding: a release build shipped with debugging enabled and an Android component exported that should be private.
• Tester check: review the app manifest, exported components, file permissions, backup settings, and debug flags in the shipped build (MASVS-PLATFORM, MASVS-STORAGE).

M9: Insecure Data Storage. Sensitive data stored in plaintext files, unprotected databases, or a misused keychain/keystore: the classic mobile flaw.

• Example finding: session tokens and personal data sitting in an unencrypted local database readable from a backup.
• Tester check: dynamic analysis of everything the app writes to disk, and review of keychain/keystore use, on a running device (MASVS-STORAGE, MASVS-CRYPTO).

M10: Insufficient Cryptography. Weak algorithms, hardcoded keys, and poor key management that render encryption ineffective.

• Example finding: sensitive data “encrypted” with a hardcoded key and an outdated algorithm, trivially reversible once the key is extracted.
• Tester check: review the cryptographic primitives, key generation, and key storage the app relies on (MASVS-CRYPTO).

How a mobile test is structured

A mobile assessment aligned to MASVS works through these risks on both platforms, and the tester checks above fall into four layers:

• Static analysis of the app binary for hardcoded secrets, weak crypto, and insecure configuration
• Dynamic analysis on a running device for insecure storage, runtime tampering, and authentication bypass
• Network testing for TLS, certificate pinning, and cleartext traffic
• Backend API testing, because a mobile app is only as secure as the services behind it

MASVS pairs with the Mobile Application Security Testing Guide (MASTG), which holds the detailed test cases, and OWASP has reworked the old L1, L2 and R verification levels into MAS Profiles, which now set the depth of testing. We cover how these layers fit together on our mobile application penetration testing page, and the platform-specific differences in iOS vs Android security testing.

Frequently asked questions

Is the OWASP Mobile Top 10 2024 still current in 2026? Yes. The 2024 list is the final release and remains the current edition. There is no newer numbered version, so testing against the 2024 risks is testing against the latest standard.

What is the difference between the OWASP Mobile Top 10 and MASVS? The Top 10 is an awareness list of the ten most important risk categories. MASVS is the detailed verification standard, and MASTG is the testing guide that goes with it. A real assessment uses the Top 10 to frame the risks and MASVS/MASTG to verify them.

Does the OWASP Mobile Top 10 cover the backend? Only indirectly. The list is about the app, but most mobile apps depend on APIs, and those fall under the OWASP API Security Top 10. A complete mobile test covers both the app and its backend.

How often should we test a mobile app against it? At least annually and after any significant change to authentication, data handling, or the SDKs you bundle, since M2 supply-chain risk changes every time a dependency updates.

Use it as a testing agenda

The OWASP Mobile Top 10 is most useful as the structure for a real assessment, not a checklist to skim. If you ship an iOS or Android app that handles anything sensitive, work through these ten against your actual build before an attacker does. See what a mobile app penetration test costs: iOS and Android at one fixed price from $6,000, with a free retest. Scope a mobile assessment and we will test your app and its backend against the full list.