The Open Web Application Security Project (OWASP) is a non-profit organization that focuses on improving software security. With the increasing amount of sensitive data being stored on mobile applications, it is more important than ever to ensure proper protection.
If you're building or testing mobile applications, you already know the landscape has shifted significantly since OWASP last updated its Mobile Top 10 in 2016. Ten years is a long time in security. The latest release isn't just a refresh. Several categories are entirely new, others have been merged, and the overall focus more accurately reflects the threats teams face today.
This article walks through all ten vulnerabilities in the updated list, explains what they look like in practice, and gives you the mitigation steps that actually matter.
What Is the OWASP Mobile Top 10?
The OWASP Mobile Top 10 is a consensus list of the ten most critical security risks in mobile applications. It's maintained by the Open Web Application Security Project (OWASP), a non-profit that focuses on improving software security globally.
Security testers use it as a structured checklist. Developers use it to understand what to avoid. It's the closest thing the mobile security community has to a shared language.
The list was last updated in 2024, the first major revision since 2016. Here's how the two versions compare:
OWASP 2016
OWASP 2024
M1: Improper Platform Usage
M1: Improper Credential Usage
M2: Insecure Data Storage
M2: Inadequate Supply Chain Security
M3: Insecure Communication
M3: Insecure Authentication/Authorization
M4: Insecure Authentication
M4: Insufficient Input/Output Validation
M5: Insufficient Cryptography
M5: Insecure Communication
M6: Insecure Authorization
M6: Inadequate Privacy Controls
M7: Client Code Quality
M7: Insufficient Binary Protections
M8: Code Tampering
M8: Security Misconfiguration
M9: Reverse Engineering
M9: Insecure Data Storage
M10: Extraneous Functionality
M10: Insufficient Cryptography
Four of the ten entries are entirely new. It reflects real shifts in how mobile apps are built, deployed, and attacked.
M1: Improper Credential Usage
What it means
Hardcoded passwords, API keys, or tokens sitting directly in your application's source code or configuration files. It's more common than you'd think, and the consequences are significant.
An attacker doesn't need to intercept network traffic or compromise a server. They pull apart your APK or IPA file using static analysis tools like Jadx or Ghidra, and your credentials are right there, in plain text.
Real example
A well-documented case involved the Pic Stitch app, where AWS access keys and secrets were found hardcoded directly in the decompiled class files. Anyone with the APK and ten minutes could access the company's S3 buckets.
M1 also covers
Insecure credential transmission: Using HTTP instead of HTTPS means credentials travel unencrypted. A passive observer on the same network captures them trivially.
Insecure credential storage: API keys stored in User Defaults (iOS), Shared Preferences (Android), unencrypted SQLite databases, or flat files. If an attacker has physical access to the device, those are easy targets.
What to do
Remove anything that doesn't need to be hardcoded. Move validation server-side.
Where something must remain in the app, obfuscate it, it won't stop a determined attacker, but it raises the cost significantly.
Always use HTTPS.
Use Android Keystore and Apple Keychain for credential storage. That's what they're there for.
M2: Inadequate Supply Chain Security
What it means
Your app doesn't exist in isolation. It probably pulls in dozens of third-party SDKs, libraries, and frameworks. Each one is a potential attack surface you didn't write and may not be monitoring.
The question isn't hypothetical: what happens when one of those modules contains malware? Or has a known vulnerability that never gets patched because the maintainer abandoned it?
What to do
Use OWASP Dependency Check to scan your dependencies automatically.
Monitor vulnerability databases (NVD, GitHub Advisories) for issues in the libraries you use.
Only use third-party components with a clear maintenance history and a good security track record.
If your team is the one publishing SDKs or libraries:
Sign your code digitally so consumers can verify its integrity.
Conduct regular code reviews and security testing.
Adopt a Secure Software Development Lifecycle (SSDLC) - security requirements at planning, threat modelling at design, secure coding practices in development, and security testing before deployment. Not as an afterthought, throughout.
Apply for Your Free 30-Day App Protector Trial
Get full access to advanced mobile security for 30 days, featuring both App Hardening to make your app tamper-proof and App Shielding to actively detect and block attacks in real time. Explore a user-friendly portal and see how your app stays protected at every stage. No upfront payment needed.
Authentication verifies who someone is. Authorization determines what they're allowed to do. Both can be broken, and both are frequently found broken in mobile app testing.
Common failure patterns include:
No authentication check on individual API endpoints - the mobile app enforces it, but the backend doesn't. Strip out the app's UI layer and the endpoints are wide open.
Hidden requests - no server-side check that the request comes from an authenticated user.
Relying on the interface - hiding a button in the UI is not the same as restricting access to the underlying functionality.
M3 also covers
Weak passwords - even if they're stored securely, a weak password is cracked quickly in a brute-force attack or server compromise.
IDOR (Insecure Direct Object Reference) - a user changes an account ID in a request from 1234 to 1235 and retrieves someone else's data. Classic authorization failure.
LDAP group data being passed to the client and used to make authorization decisions client-side.
What to do
Authenticate every request server-side. Every one. No exceptions.
Check authorization on every request, not just at login. Apply the principle of least privilege.
Use tokens with integrity guarantees - JWT with proper signature validation, for example.
Enforce minimum password complexity.
Always verify resource ownership before granting access.
Validate all data server-side, regardless of what the client sends.
M4: Insufficient Input/Output Validation
What it means
This one is new to the list, which is overdue. When apps don't validate data coming in from users or external sources, and don't sanitize data going out, the attack surface is enormous.
What becomes possible without proper validation
SQL injection - an attacker manipulates a database query by injecting SQL into a login field. Instead of checking a password, the query returns all users and grants access.
Command injection - input gets passed directly to a system command. In the worst cases, the attacker gains control of the device.
XSS (Cross-Site Scripting) - malicious scripts execute in a WebView, running with the app's permissions.
What to do
Validate all input: enforce allowed formats, lengths, and data types.
Sanitize data before processing - remove dangerous characters before they reach a database or system call.
Verify data integrity.
Use established validation libraries rather than rolling your own.
Always perform validation server-side, even if you also validate client-side.
M5: Insecure Communication
What it means
Sensitive data travelling without adequate protection. This covers everything from unencrypted HTTP connections to improperly configured TLS to apps that accept any certificate without checking whether it's valid.
A man-in-the-middle (MitM) attacker positioned between your app and its backend can intercept, read, and modify traffic. How easy that is depends almost entirely on how well you've implemented your transport security.
Common failures
No certificate validation - the app accepts any certificate, including self-signed attacker-controlled ones.
Outdated TLS versions - TLS 1.0 and 1.1 have known vulnerabilities. They shouldn't be in use.
Personal data sent without encryption - PII, passwords, or authentication tokens over plain HTTP.
2FA implemented poorly - the app uses two-factor authentication but sends the second factor over an unencrypted channel. The second factor is then no longer secret.
What to do
Require HTTPS (TLS 1.2+) across all communications. Disable HTTP entirely.
Validate certificate authenticity.
Implement certificate pinning - don't trust the device's certificate store; pin the specific certificate or public key your app expects.
On iOS: avoid setAllowsAnyHTTPSCertificate; use NSStreamSocketSecurityLevelTLSv1.
On Android: avoid AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. Review checkServerTrusted carefully, and do not override onReceivedSslError to ignore SSL errors.
M6: Inadequate Privacy Controls
What it means
This category is new and reflects the increasingly serious regulatory environment around personal data. PII (Personally Identifiable Information) includes name, surname, national ID numbers, physical and email addresses, professional qualifications, credit information, and health data.
The problem occurs when an app collects, stores, or shares personal data without the user's knowledge or consent.
Real examples
Insufficient log sanitization - personal data ends up in application logs that weren't designed to hold it. Logs often flow through multiple systems without the same protections applied to production data.
PII in URL query parameters - a URL like https://vulnerablesite/sign_in?email_otp=true&otp_code=123456&user[email]=john.doe@example.com exposes personal data to server logs, analytics platforms, browser history, and referrer headers. This is a real pattern found in real applications.
Personal data in backups - device backups that aren't encrypted or scoped properly.
What to do
Sanitize logs - scrub personal data before it's written anywhere.
Never send PII in URL query parameters. Use request headers or a JSON body (over HTTPS).
Define explicitly what gets included in backups, and encrypt backups that contain sensitive data.
Obtain user consent before collecting data, and collect only what you actually need.
M7: Insufficient Binary Protections
What it means
Once your app is installed on a device, an attacker has physical access to the binary. Without binary protections, they can analyse it statically to extract secrets, or manipulate it dynamically at runtime.
What attackers look for
Hardcoded API keys and visible symbols (function and variable names).
The ability to manipulate logic using tools like Frida - removing licence checks, manipulating in-app purchases, bypassing security controls.
Hardcoded AI models (extractable IP).
Any other intellectual property embedded in the application.
What to do
Obfuscate strings and symbols - make the binary meaningfully harder to read.
Implement integrity checks - detect whether the app has been tampered with.
Add runtime checks - detect debuggers, emulators, Frida hooks, and other signs of dynamic analysis.
These measures don't make an app impenetrable, but they raise the cost of attack substantially and protect intellectual property in the process.
Apply for Your Free 30-Day App Protector Trial
Get full access to advanced mobile security for 30 days, featuring both App Hardening to make your app tamper-proof and App Shielding to actively detect and block attacks in real time. Explore a user-friendly portal and see how your app stays protected at every stage. No upfront payment needed.
The security capability exists, it's just not enabled. Or it's configured incorrectly. This covers system-level settings as much as application-level ones, and can be accidental or, occasionally, intentional (debug builds accidentally shipped to production, for instance).
Common examples
Shipping a debug build instead of a release build - exposes logs, stack traces, and sometimes remote debugging interfaces.
Unchanged default passwords on backend services or admin interfaces.
Excessive file permissions on documents the app accesses.
Over-permissioned applications - the classic example is a flashlight app requesting access to contacts, location, and camera.
What to do
Use a SAST (Static Application Security Testing) scanner to catch misconfiguration issues early.
Enforce mandatory changing of default passwords.
Apply the principle of least privilege - request only the permissions your app genuinely needs. If you can't explain why your app needs a particular permission, it probably doesn't need it.
M9: Insecure Data Storage
What it means
Sensitive data stored on the device without adequate protection. This is related to M1 (which specifically covered credentials), but M9 covers the full range: PII, authentication tokens, API keys, session data, and anything else that would be valuable to an attacker.
Common insecure storage locations include Shared Preferences (Android), User Defaults (iOS), unencrypted SQLite databases, flat files, and cloud storage buckets with overly permissive access controls.
What to do
Anything that must be stored client-side: obfuscate or encrypt it.
Use Keychain (iOS) and Keystore (Android) for secrets that need to persist.
Encrypt log files and temporary files that may contain sensitive data.
When using cloud storage, apply encryption in transit and at rest, and audit access controls on your buckets.
M10: Insufficient Cryptography
What it means
Using cryptography that doesn't hold up, whether that's outdated algorithms, home-grown implementations, or insufficient key lengths.
Common failures
MD5 and SHA-1 - both are vulnerable to collision attacks. Using them for integrity verification means that integrity can be broken.
Brute-force against weak passwords - even if the password is stored securely, a short or simple password is recovered quickly.
MitM attacks enabled by weak certificate algorithms - if the certificate chain uses outdated cryptographic algorithms, an attacker can break the chain.
Custom cryptographic functions - cryptography is hard to get right. Functions that haven't been put through years of public scrutiny and peer review almost certainly contain vulnerabilities.
What to do
Use well-established, peer-reviewed cryptographic algorithms. Don't invent your own.
Enforce strong password requirements.
Use PBKDF2 (or bcrypt, or Argon2) for password hashing - not plain SHA-256.
Keep certificates current and monitor TLS version support.
Enhancing Mobile Security: MASTG and MASVS
Beyond the Top 10 list, OWASP provides two complementary resources worth knowing.
The OWASP Mobile Application Security Testing Guide (MASTG) gives you a structured methodology for evaluating mobile app security in depth, covering both iOS and Android in detail. If your team conducts penetration testing or security assessments, this is the reference you want. Read the MASTG →
The OWASP Mobile Application Security Verification Standard (MASVS) is the industry standard for mobile application security requirements. It gives developers and architects a framework for building secure apps, and gives security testers a consistent baseline for what "secure" means. Read the MASVS →
Putting It Into Practice
The latest list reflects how mobile threats have evolved. Supply chain attacks, privacy violations, and binary manipulation are all now explicitly on the radar.
The good news: most of these vulnerabilities are preventable with consistent application of known practices. Server-side validation. Proper encryption. Minimal permissions. Dependency monitoring. Binary protections.
It's a list of the ten most critical security risks in mobile applications, maintained by the Open Web Application Security Project. It was last updated in 2024 and serves as a widely used reference for developers and security testers.
Four categories are entirely new in 2024: Improper Credential Usage, Inadequate Supply Chain Security, Insufficient Input/Output Validation, and Inadequate Privacy Controls. Two categories were merged, one was reworded, and several were repositioned in priority order.
Improper Credential Usage (M1) is consistently among the most commonly found vulnerabilities in mobile security assessments. Hardcoded API keys and insecure credential storage are widespread even in mature codebases.
Certificate pinning is a technique where your app is configured to trust only a specific certificate or public key, rather than accepting any certificate signed by a trusted CA. It protects against man-in-the-middle attacks where an attacker presents a valid but attacker-controlled certificate.
Yes. M6 (Inadequate Privacy Controls) directly maps to GDPR and similar data protection regulations. Collecting, storing, or sharing PII without user consent or appropriate safeguards is both a security vulnerability and a regulatory risk.
