{"id":100010,"date":"2026-10-09T00:47:43","date_gmt":"2026-10-09T00:47:43","guid":{"rendered":"http:\/\/nandee-post-5"},"modified":"2026-10-09T00:47:43","modified_gmt":"2026-10-09T00:47:43","slug":"owasp-mobile-top-10","status":"publish","type":"post","link":"https:\/\/www.nandee.ai\/blog\/owasp-mobile-top-10\/","title":{"rendered":"OWASP Mobile Top 10 (2024): A Complete Guide for Developers"},"content":{"rendered":"

Most mobile breaches do not start with a clever zero-day. They start with someone downloading your app, unzipping it, and reading what you shipped: an API key in a constants file, a debug flag left on, a token sitting in plain storage. Code obfuscation renames classes and methods, but the strings an attacker wants usually survive it. The 2024 Top 10 is built around exactly these everyday mistakes.<\/p>\n

The OWASP Mobile Top 10 (2024) is the ten most critical security risks in Android and iOS apps, and it is the first full update since 2016. If you ship a mobile app, this list is the fastest way to know where attackers look first and what your pentest report will flag.<\/p>\n

This article covers each risk from M1 to M10 with a realistic example, the fix, and how to test for it. It is written for mobile developers, security engineers, and startup CTOs who need a working checklist, not a theory lecture.<\/p>\n

Quick answer: the 2024 list<\/strong><\/p>\n

    \n
  1. \n

    M1: Improper Credential Usage<\/p>\n<\/li>\n

  2. \n

    M2: Inadequate Supply Chain Security<\/p>\n<\/li>\n

  3. \n

    M3: Insecure Authentication\/Authorization<\/p>\n<\/li>\n

  4. \n

    M4: Insufficient Input\/Output Validation<\/p>\n<\/li>\n

  5. \n

    M5: Insecure Communication<\/p>\n<\/li>\n

  6. \n

    M6: Inadequate Privacy Controls<\/p>\n<\/li>\n

  7. \n

    M7: Insufficient Binary Protections<\/p>\n<\/li>\n

  8. \n

    M8: Security Misconfiguration<\/p>\n<\/li>\n

  9. \n

    M9: Insecure Data Storage<\/p>\n<\/li>\n

  10. \n

    M10: Insufficient Cryptography<\/p>\n<\/li>\n<\/ol>\n

    What changed from 2016 to 2024<\/strong><\/p>\n

    Four categories are new, four old ones merged into two, and the rest moved or were renamed. The biggest shift: credentials and the supply chain now sit at the top, while insecure data storage fell from M2 to M9.<\/p>\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n

    2024 category<\/p>\n<\/td>\n

    		\n

    Came from (2016)<\/p>\n<\/td>\n

    		\n

    Change<\/p>\n<\/td>\n<\/tr>\n

    \n

    M1 Improper Credential Usage<\/p>\n<\/td>\n

    		\n

    None<\/p>\n<\/td>\n

    		\n

    New<\/p>\n<\/td>\n<\/tr>\n

    \n

    M2 Inadequate Supply Chain Security<\/p>\n<\/td>\n

    		\n

    None<\/p>\n<\/td>\n

    		\n

    New<\/p>\n<\/td>\n<\/tr>\n

    \n

    M3 Insecure Authentication\/Authorization<\/p>\n<\/td>\n

    		\n

    M4 Insecure Authentication + M6 Insecure Authorization<\/p>\n<\/td>\n

    		\n

    Merged<\/p>\n<\/td>\n<\/tr>\n

    \n

    M4 Insufficient Input\/Output Validation<\/p>\n<\/td>\n

    		\n

    None<\/p>\n<\/td>\n

    		\n

    New<\/p>\n<\/td>\n<\/tr>\n

    \n

    M5 Insecure Communication<\/p>\n<\/td>\n

    		\n

    M3 Insecure Communication<\/p>\n<\/td>\n

    		\n

    Moved down<\/p>\n<\/td>\n<\/tr>\n

    \n

    M6 Inadequate Privacy Controls<\/p>\n<\/td>\n

    		\n

    None<\/p>\n<\/td>\n

    		\n

    New<\/p>\n<\/td>\n<\/tr>\n

    \n

    M7 Insufficient Binary Protections<\/p>\n<\/td>\n

    		\n

    M8 Code Tampering + M9 Reverse Engineering<\/p>\n<\/td>\n

    		\n

    Merged<\/p>\n<\/td>\n<\/tr>\n

    \n

    M8 Security Misconfiguration<\/p>\n<\/td>\n

    		\n

    M10 Extraneous Functionality<\/p>\n<\/td>\n

    		\n

    Renamed, moved up<\/p>\n<\/td>\n<\/tr>\n

    \n

    M9 Insecure Data Storage<\/p>\n<\/td>\n

    		\n

    M2 Insecure Data Storage<\/p>\n<\/td>\n

    		\n

    Moved down<\/p>\n<\/td>\n<\/tr>\n

    \n

    M10 Insufficient Cryptography<\/p>\n<\/td>\n

    		\n

    M5 Insufficient Cryptography<\/p>\n<\/td>\n

    		\n

    Moved down<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    A lower rank does not mean a risk got safer. It means attackers now get more value from stolen keys, poisoned SDKs, and broken backends than from reading a local database. OWASP also listed data leakage, hardcoded secrets, unprotected endpoints, and unsafe sharing as near misses for the list (OWASP Mobile Top 10 2024<\/span><\/a>, Bureau Veritas<\/span><\/a>).<\/p>\n

    The 10 risks, one by one<\/strong><\/p>\n

    Each risk below follows the same pattern: what it is, what it looks like in a real app, how to fix it, and how to test for it. Every section ends with the deeper article in this series.<\/p>\n

    M1: Improper Credential Usage<\/strong><\/p>\n

    What it is.<\/strong> Hardcoded API keys, passwords, or tokens inside the app, or credentials sent and stored carelessly. Anything in the binary is public: an APK unzips in seconds and an IPA is one decrypt away.<\/p>\n

    Example.<\/strong> A fintech app ships a live payment provider secret key in its Kotlin code so the app can create charges directly.<\/p>\n

    \/\/ Bad: anyone with jadx can read this<\/em>
    <\/span>private<\/strong><\/span> <\/span>const<\/strong><\/span> <\/span>val<\/strong><\/span> <\/span>PAYMENTS_KEY<\/span> <\/span>=<\/span> <\/span>“sk_live_…”<\/span><\/p>\n

    Fix.<\/strong> Keep secrets on your server. The app authenticates the user, then asks your backend for a short-lived, narrowly scoped token. Store user session tokens in Android Keystore or iOS Keychain, never in plain preferences. Rotate any key that has ever shipped in a build.<\/p>\n

    Test.<\/strong> Decompile with jadx or apktool and search for key patterns (sk_live, AIza, AKIA, Bearer). Run strings on the iOS binary. Add a secret scanner to CI so a key never reaches a release.<\/p>\n

    Go deeper:<\/strong> M1 Improper Credential Usage: Examples and Fixes; Hardcoded API Keys in Mobile Apps: How Attackers Find Them.<\/p>\n

    M2: Inadequate Supply Chain Security<\/strong><\/p>\n

    What it is.<\/strong> Risk that enters through code you did not write: third-party SDKs, open-source packages, build tools, and CI pipelines. The typical mobile app ships dozens of SDKs, and each one runs with your app\u2019s permissions.<\/p>\n

    Example.<\/strong> An ad or analytics SDK update starts collecting device data your privacy policy never mentions, or a compromised package lands in your build through an unpinned version range.<\/p>\n

    Fix.<\/strong> Pin dependency versions and commit lockfiles. Generate an SBOM for every release. Review what each SDK collects and which permissions it adds to your merged manifest. Protect signing keys and CI secrets as carefully as production credentials.<\/p>\n

    Test.<\/strong> Diff the merged AndroidManifest.xml and the iOS privacy manifests between releases. Run software composition analysis (SCA) on Gradle, CocoaPods, Swift Package Manager, npm, and pub dependencies.<\/p>\n

    Go deeper:<\/strong> M2 Inadequate Supply Chain Security in Mobile Apps; Third-Party SDK Risk: Auditing What You Ship; Mobile SBOM: Why You Need One and How to Generate It.<\/p>\n

    M3: Insecure Authentication\/Authorization<\/strong><\/p>\n

    What it is.<\/strong> Weak login flows and, more often, authorization decisions made on the device instead of the server. If the app decides who is an admin, an attacker with Frida decides too.<\/p>\n

    Example.<\/strong> The app hides a premium screen unless user.isPremium == true, and the API behind that screen never checks the flag. Changing one boolean at runtime unlocks paid features. A related pattern: an endpoint like \/api\/orders\/{id} returns any user\u2019s order when you change the ID (BOLA\/IDOR).<\/p>\n

    Fix.<\/strong> Enforce every authorization decision on the server, on every request. Use OAuth 2.0 with PKCE and the system browser for sign-in. Bind sessions to short-lived tokens with server-side revocation.<\/p>\n

    Test.<\/strong> Intercept traffic with a proxy, then replay requests with another user\u2019s IDs and with a lower-privilege token. Hook client checks with Frida to confirm the server still refuses.<\/p>\n

    Go deeper:<\/strong> Securing OAuth and PKCE in Mobile Apps; JWT Handling Mistakes in Mobile Apps; BOLA\/IDOR Vulnerabilities in Mobile Backends.<\/p>\n

    M4: Insufficient Input\/Output Validation<\/strong><\/p>\n

    What it is.<\/strong> The app trusts data from deep links, intents, WebViews, QR codes, clipboard, files, or its own backend. Mobile apps have far more input channels than most developers track.<\/p>\n

    Example.<\/strong> A deep link myapp:\/\/open?url= loads any URL into a WebView that has JavaScript and a native bridge enabled. An attacker sends a link and gets code running with access to the bridge.<\/p>\n

    Fix.<\/strong> Validate every external input against an allowlist. Use parameterized queries in SQLite and content providers. Restrict WebViews to trusted origins and avoid exposing native interfaces to untrusted content.<\/p>\n

    Test.<\/strong> Enumerate entry points from the manifest and Info.plist, then fuzz each one with malformed and malicious values using adb, Drozer, or crafted links.<\/p>\n

    Go deeper:<\/strong> Android Intent Vulnerabilities and How to Prevent Them; WebView Security in Android: 7 Common Mistakes; Deep Link and App Link Hijacking on Android.<\/p>\n

    M5: Insecure Communication<\/strong><\/p>\n

    What it is.<\/strong> Data sent in cleartext, TLS validation turned off, or trust decisions that let an attacker on the same Wi-Fi read and modify traffic.<\/p>\n

    Example.<\/strong> A developer adds a custom TrustManager that accepts every certificate to get past a staging error, and it ships to production.<\/p>\n

    Fix.<\/strong> Never override certificate validation. Block cleartext traffic and, for high-risk apps, pin your API\u2019s public keys with a backup pin.<\/p>\n

    <!– res\/xml\/network_security_config.xml –><\/em><\/span>
    <<\/span>network-security-config<\/strong>>
        <<\/span>base-config<\/strong> cleartextTrafficPermitted=“false”<\/span> \/>
        <<\/span>domain-config<\/strong>>
            <<\/span>domain<\/strong> includeSubdomains=“true”<\/span>><\/span>    api.example.com<\/span><\/a><\/<\/span>domain<\/strong>>
            <<\/span>pin-set<\/strong> expiration=“2027-01-01”<\/span>>
                <<\/span>pin<\/strong> digest=“SHA-256”<\/span>>PRIMARY_KEY_HASH_BASE64=<\/<\/span>pin<\/strong>>
                <<\/span>pin<\/strong> digest=“SHA-256”<\/span>>BACKUP_KEY_HASH_BASE64=<\/<\/span>pin<\/strong>>
            <\/<\/span>pin-set<\/strong>>
        <\/<\/span>domain-config<\/strong>>
    <\/<\/span>network-security-config<\/strong>><\/span><\/p>\n

    On iOS, keep App Transport Security on and justify every exception.<\/p>\n

    Test.<\/strong> Route the device through Burp Suite or mitmproxy with an untrusted certificate. A secure app refuses to connect.<\/p>\n

    Go deeper:<\/strong> M5 Insecure Communication: Finding and Fixing TLS Flaws; Network Security Config: Certificate Pinning on Android; App Transport Security (ATS): What Exceptions Really Cost You.<\/p>\n

    M6: Inadequate Privacy Controls<\/strong><\/p>\n

    What it is.<\/strong> Collecting, logging, or sharing personal data (PII) beyond what the app needs or the user agreed to. This is the category where security findings become GDPR, HIPAA, and DPDP problems.<\/p>\n

    Example.<\/strong> Email addresses and GPS coordinates land in crash logs and analytics events, then flow to a third-party dashboard.<\/p>\n

    Fix.<\/strong> Collect the minimum. Scrub PII from logs, crash reports, and analytics. Keep your Google Play Data Safety form and iOS privacy manifest accurate, and honor consent before any SDK initializes.<\/p>\n

    Test.<\/strong> Watch logcat and the iOS console during a full user journey. Inspect outbound analytics payloads in your proxy.<\/p>\n

    Go deeper:<\/strong> iOS Privacy Manifests: Requirements and Compliance Guide; GDPR and Mobile Apps: Data Collection Pitfalls; Google Play Data Safety Section: Getting It Right.<\/p>\n

    M7: Insufficient Binary Protections<\/strong><\/p>\n

    What it is.<\/strong> An app that is easy to reverse engineer, modify, and redistribute. This merges the old Code Tampering and Reverse Engineering categories.<\/p>\n

    Example.<\/strong> An attacker decompiles your app, removes the license check, re-signs it, and publishes a mod APK. Or they hook your root check with Frida and return false.<\/p>\n

    Fix.<\/strong> Obfuscate release builds with R8 or a commercial tool. Add runtime checks for root, jailbreak, emulators, debuggers, and hooking frameworks. Verify app integrity on the server with Play Integrity or App Attest, because any check that only runs on the device can be patched out. Runtime application self-protection (RASP) tools package these checks.<\/p>\n

    Test.<\/strong> Decompile the release build and check how readable it is. Repackage it and see whether the app or your backend notices. Try standard Frida bypass scripts.<\/p>\n

    Go deeper:<\/strong> What Is RASP for Mobile Apps?; How Attackers Reverse Engineer Android APKs; App Repackaging and Cloning Attacks: How to Stop Them.<\/p>\n

    M8: Security Misconfiguration<\/strong><\/p>\n

    What it is.<\/strong> Insecure defaults and leftover settings: debug flags, backups, exported components, and permissive platform settings.<\/p>\n

    Example.<\/strong> A release build has android:debuggable=”true”, or an exported Activity with no permission lets any installed app open an internal admin screen. On iOS, NSAllowsArbitraryLoads is left on from development.<\/p>\n

    Fix.<\/strong> Review the merged manifest for every release: debuggable, allowBackup, exported, permissions, and usesCleartextTraffic. Keep a separate, locked-down release configuration and fail the build if it drifts.<\/p>\n

    Test.<\/strong> Run aapt dump xmltree or open the manifest in jadx. Check Info.plist and entitlements. Use Drozer to call exported components directly.<\/p>\n

    Go deeper:<\/strong> M8 Security Misconfiguration in Android and iOS Apps; Android Manifest Security Review: What to Check; Exported Activities, Services, and Receivers: The Hidden Attack Surface.<\/p>\n

    M9: Insecure Data Storage<\/strong><\/p>\n

    What it is.<\/strong> Sensitive data saved on the device where other apps, backups, or anyone holding the phone can read it: plain SharedPreferences, NSUserDefaults, SQLite files, logs, caches, and screenshots.<\/p>\n

    Example.<\/strong> A refresh token sits in plain text in SharedPreferences. Anyone with a rooted device or an ADB backup reads it and takes over the account.<\/p>\n

    Fix.<\/strong> Store secrets in the Keychain on iOS and use Android Keystore-backed keys to encrypt data on Android. Choose the strictest accessibility level the feature allows.<\/p>\n

    let<\/strong><\/span> query<\/span>:<\/span> [<\/span>String:<\/span> Any]<\/span> =<\/span> [<\/span>
        kSecClass as<\/strong><\/span> String:<\/span> kSecClassGenericPassword,<\/span>
        kSecAttrAccount as<\/strong><\/span> String:<\/span> “refresh_token”<\/span>,<\/span>
        kSecValueData as<\/strong><\/span> String:<\/span> tokenData,<\/span>
        kSecAttrAccessible as<\/strong><\/span> String:<\/span> kSecAttrAccessibleWhenUnlockedThisDeviceOnly
    ]<\/span>
    let<\/strong><\/span> status<\/span> =<\/span> SecItemAdd(<\/span>query as<\/strong><\/span> CFDictionary,<\/span> nil<\/strong><\/span>)<\/span><\/p>\n

    Test.<\/strong> On a rooted or jailbroken test device, walk the app\u2019s sandbox (\/data\/data\/<package> on Android, the app container on iOS) after a full session and grep for tokens, emails, and card data.<\/p>\n

    Go deeper:<\/strong> M9 Insecure Data Storage: Where Mobile Apps Leak Data; Android Keystore: How to Store Secrets Correctly; iOS Keychain Security: Correct Usage and Common Pitfalls.<\/p>\n

    M10: Insufficient Cryptography<\/strong><\/p>\n

    What it is.<\/strong> Weak algorithms, bad modes, hardcoded keys, static IVs, or home-made crypto.<\/p>\n

    Example.<\/strong> The app encrypts local data with AES in ECB mode using a key stored as a string constant, so the encryption adds nothing.<\/p>\n

    Fix.<\/strong> Use platform crypto APIs with modern defaults: AES-GCM for data, keys generated and held in Keystore or Keychain (or the Secure Enclave), and a fresh random nonce per encryption. Never use MD5 or SHA-1 for anything security-relevant.<\/p>\n

    Test.<\/strong> Search decompiled code for AES\/ECB, DES, MD5, SHA1, and hardcoded byte arrays. Hook crypto calls with Frida to see keys and IVs at runtime.<\/p>\n

    Go deeper:<\/strong> Securing Swift Apps: Data Protection Classes Explained; Android Keystore: How to Store Secrets Correctly.<\/p>\n

    How the Top 10 maps to MASVS and MASTG<\/strong><\/p>\n

    The Top 10 tells you what to worry about; the OWASP MAS project tells you exactly what to build and test. Use the Top 10 to prioritize and explain risk, and use MASVS as the requirement you verify against.<\/p>\n