OWASP Mobile Top 10 2024: Risks, Testing, and Secure App Controls

The OWASP Mobile Top 10 2024 lists major security risks in mobile applications and their supporting development process. Its categories cover credentials, supply chains, authentication and authorization, input and output validation, communication, privacy, binary protection, configuration, local storage, and cryptography.

The official OWASP Mobile Top 10 page identifies the 2024 list as the final current release. It replaces the 2016 edition, so older reports and tools may use different M-numbers and names. The year should appear beside any finding mapped to the list.

A mobile app is one part of a larger system. The installed binary runs on a device the application owner does not control, talks to backend APIs, receives links and platform messages, uses third-party SDKs, and may keep sensitive state locally. Security testing must cover those connections rather than treating the package as an isolated artifact.

Key Takeaways

• Assume an attacker can inspect, modify, automate, and run the mobile client on a controlled device.
• Enforce authentication, authorization, business rules, and data access on trusted backend services.
• Test the shipped application, its dependencies, build pipeline, mobile platform integrations, APIs, and privacy behavior together.
• Keep sensitive data and credentials off the device where possible, and use platform security APIs when local protection is necessary.

What Changed Since the 2016 Mobile Top 10

Improper Credential Usage is now M1, while Inadequate Supply Chain Security enters at M2. Authentication and authorization are combined at M3, and privacy controls receive a named category at M6. Binary protection, configuration, data storage, and cryptography remain visible concerns with updated ordering.

The change reflects the wider path through which mobile software reaches users. An application includes build services, package repositories, SDKs, signing systems, app-store accounts, backend APIs, and release configuration. A secure code review can miss compromise in any of those components.

The list does not replace the OWASP Mobile Application Security Verification Standard or Mobile Application Security Testing Guide. The Top 10 supports awareness and prioritization, while those resources provide deeper requirements and test methods.

OWASP Mobile Top 10 2024 Risks Explained

M1: Improper credential usage

Mobile packages can contain API keys, passwords, signing material, client secrets, or reusable service tokens. Obfuscation does not make a credential secret because an attacker can inspect files, memory, traffic, and runtime behavior on a device they control.

Do not embed credentials that grant privileged backend access. Use per-user or per-device enrollment, short sessions, platform-backed key storage, and server-side revocation. Treat identifiers and public API keys according to their actual power rather than labeling every string a secret.

M2: Inadequate supply chain security

Mobile applications depend on SDKs, packages, build plugins, hosted services, signing systems, and app-store accounts. A malicious dependency or compromised release path can reach every user through a trusted update.

Inventory and pin dependencies, review SDK permissions and data collection, protect source and build identities, and isolate signing keys. Generate reproducible evidence for each release and monitor ownership or version changes in third-party components. Remove unused SDKs rather than leaving dormant code and permissions in the binary.

M3: Insecure authentication and authorization

Authentication flaws allow account or session compromise, while authorization flaws let a valid caller reach another user’s data or restricted functions. Client-side role checks and hidden screens do not protect backend endpoints because attackers can send requests directly.

Enforce both controls on the server, validate tokens completely, and protect enrollment, recovery, refresh, and logout. Test object, property, and function access across users and roles. Device biometrics should unlock a protected local credential, not replace server authorization.

M4: Insufficient input and output validation

Mobile apps receive input from users, deep links, QR codes, clipboard, files, notifications, inter-process communication, web views, APIs, and platform intents. Unsafe data can reach queries, paths, web content, parsers, logs, or native code.

Validate data by context and use safe platform APIs. Restrict exported components and deep-link parameters, encode content for web views, parameterize database operations, and reject unexpected schemas. Backend services must validate again because a modified client can bypass local checks.

M5: Insecure communication

Sensitive traffic can be exposed by missing TLS, weak certificate validation, cleartext exceptions, unsafe redirects, or third-party endpoints that receive more data than intended. A secure primary API does not cover analytics, advertising, crash, or support SDK traffic.

Use current TLS through platform networking libraries and validate hostnames and certificate chains. Remove broad cleartext allowances, review every destination, and minimize transmitted data. Certificate pinning may help specific threat models, but it adds rotation and recovery risk and cannot replace correct platform validation.

M6: Inadequate privacy controls

Privacy failures occur when applications collect, infer, retain, share, or expose personal data beyond a stated and necessary purpose. Permissions, advertising identifiers, location, contacts, diagnostics, and behavioral events can reveal more than an interface suggests.

Create a data inventory that follows each field from collection through SDKs, backend systems, exports, retention, and deletion. Request platform permissions in context, minimize collection, honor user choices, and test deletion. Verify actual network and storage behavior against notices and settings.

M7: Insufficient binary protections

Attackers can reverse engineer application code, modify control flow, attach debuggers, hook functions, and redistribute altered packages. Binary protection raises effort but cannot make client-side secrets or authorization trustworthy.

Remove debug features and sensitive symbols from production, use platform signing, verify update channels, and apply obfuscation where it protects meaningful intellectual property. Detect tampering or risky device state as a signal, then make proportionate server decisions. Avoid hard failures that lock out legitimate users without a recovery path.

M8: Security misconfiguration

Mobile configuration includes exported components, backup settings, file sharing, web view options, debug flags, entitlements, permissions, network policies, logging, and environment endpoints. Build variants can ship a test setting into production even when source defaults appear safe.

Define release baselines and inspect the final package. Minimize permissions and exposed components, disable debugging, restrict backups, remove test endpoints, and review platform declarations. Compare Android and iOS behavior because their permission and storage models differ.

M9: Insecure data storage

Sensitive data may remain in preferences, databases, files, caches, screenshots, logs, backups, clipboard, notifications, or memory. Application sandboxing limits ordinary cross-app access but does not protect data on a compromised device or from unsafe backup and sharing paths.

Store less data and keep retention short. Use platform key stores for keys, file protection or encrypted storage for appropriate records, and explicit backup rules. Clear data at logout where the security model requires it and avoid displaying secrets in notifications or recent-app previews.

M10: Insufficient cryptography

Cryptographic failures include obsolete algorithms, predictable random values, fixed initialization vectors, reused nonces, hardcoded keys, custom protocols, and incorrect certificate handling. Correct algorithms still fail when key generation, storage, rotation, or deletion is weak.

Use reviewed platform libraries and current algorithms, generate keys with secure randomness, and protect them with hardware-backed storage where available. Separate encryption keys by purpose and user, plan rotation, and authenticate encrypted data. Do not invent a cipher or copy an old code sample without checking current platform guidance.

Test the Mobile Client as an Untrusted Client

Install the production package on physical and virtual devices, then inspect files, logs, backups, memory, traffic, deep links, exported components, and runtime behavior. Repeat tests on a rooted or jailbroken research device where permitted. The goal is to learn what a capable user can observe and change.

Modify requests and client state to bypass screens, timers, and role checks. Call the backend directly with altered identifiers, fields, methods, and tokens. A local control may improve user experience, but only the server can make a reliable decision about protected data and actions.

Review offline and interrupted states. Expired sessions, revoked devices, failed updates, partial synchronization, and lost connectivity can leave cached data or unsafe fallback behavior. Test account deletion and device replacement as carefully as initial sign-in.

Review the Shipped Package and Release Path

Source code does not show every generated permission, included dependency, configuration value, or signing property. Extract and inspect the release artifact that users receive. Compare it with the approved dependency inventory and environment configuration.

Protect app-store and signing accounts with strong individual authentication and limited roles. Separate build from release approval, preserve artifact hashes and provenance, and rehearse emergency updates. Monitor for lookalike packages and unauthorized signing certificates where the distribution ecosystem permits it.

SDK review needs privacy and security evidence. Record what data each SDK receives, which domains it contacts, which permissions it adds, and how it updates. A dependency that appears harmless at compile time can change behavior through remote configuration.

Mobile and API Security Reviews Should Be Connected

Most mobile applications rely on APIs for identity, data, and business operations. The client review finds local storage, platform, communication, binary, and configuration issues. The API review finds object authorization, function access, resource abuse, inventory, and backend trust failures.

Use the OWASP API Security Top 10 guide beside the mobile list. Share accounts, tokens, traffic captures, schemas, and business-flow models between the test streams. Findings should identify whether the root control belongs in the client, backend, build pipeline, or several places.

Frequently Asked Questions

What is the latest OWASP Mobile Top 10 version?

The current final release is the OWASP Mobile Top 10 2024. It replaces the 2016 list and changes category names and ordering. Reports should include 2024 when using identifiers such as M1 or M8.

Can obfuscation protect secrets in a mobile app?

Obfuscation can increase reverse-engineering effort, but the application must recover any embedded credential to use it. An attacker controlling the device can inspect runtime memory, hook calls, or observe network requests. Privileged backend credentials should not be distributed inside the app.

Is certificate pinning required for every mobile application?

Certificate pinning can reduce some interception risks, but it creates certificate rotation and outage concerns. Correct TLS and hostname validation through current platform libraries is the baseline. Teams should add pinning only after evaluating their threat model, operational recovery, and supported platforms.

Does the Mobile Top 10 cover backend API vulnerabilities?

It includes risks that cross the mobile system, but it is not a full API security taxonomy. Backend authorization and business-flow testing should also use the OWASP API Security Top 10. Testing the client alone cannot prove that server-side access controls work.