OWASP Mobile Top 10 (2024): The Definitive Guide for Indian Mobile App Teams

Mobile applications are now the primary attack surface for most BFSI, fintech, and consumer-internet companies in India. A web app gets a security review every quarter; the mobile app it depends on often goes years between proper assessments. The result: the bulk of high-severity findings we see in 2026 are mobile-side — broken authentication, insecure storage of session tokens, weak SSL pinning, root/jailbreak bypass, and supply-chain risks introduced by third-party SDKs.

The OWASP Foundation's Mobile Top 10 (2024 release) is the industry-standard taxonomy for these risks. This guide walks through every entry in the list, explains what it actually looks like in production code, and shows what good engineering controls look like. Where relevant we note the Indian regulatory angle (RBI, SEBI CSCRF, IRDAI) since most of our readers are accountable to one of them.

Quick orientation: the OWASP Mobile Top 10 is a list of the ten most prevalent mobile-application security risks, refreshed roughly every five years by working groups of practitioners. The 2024 release is the first major revision since 2016 — the structure was rewritten from the ground up, several legacy entries were merged, and supply-chain risk got its own slot.

---

What's new in 2024

If you last read OWASP Mobile Top 10 in 2016, almost every line item has been renamed, reordered, or merged. The headline changes:

• M1 is now "Improper Credential Usage" — broader than the old "Weak Server-Side Controls"; covers hard-coded API keys, embedded credentials, and predictable token derivation.
• M2: Inadequate Supply Chain Security is brand-new in 2024 — a direct response to incidents where compromised SDKs (analytics, ads, push) were the entry point.
• M5 Insecure Communication absorbed both the old "Insecure Communication" and parts of "Insufficient Transport Layer Protection."
• M7: Insufficient Binary Protections replaces the old "Client Code Quality" and "Code Tampering" entries — anti-tamper, RASP, and binary obfuscation collapsed into one category.
• M10: Insufficient Cryptography is unchanged in spirit but now explicitly flags hardcoded keys, weak random-number generation, and the misuse of mobile platform crypto APIs (Keychain/KeyStore).

The full 2024 list:

Rank	Risk	What it covers
M1	Improper Credential Usage	Hardcoded API keys, embedded credentials, weak token derivation, missing credential rotation
M2	Inadequate Supply Chain Security	Compromised or malicious SDKs, dependency confusion, unverified update channels
M3	Insecure Authentication / Authorization	Weak biometric fallbacks, OAuth misuse, broken session handling, missing server-side checks
M4	Insufficient Input / Output Validation	SQL injection in WebView, deeplink abuse, JavaScript bridge XSS, IPC injection
M5	Insecure Communication	Missing TLS pinning, accepting self-signed certs, plain-HTTP fallbacks
M6	Inadequate Privacy Controls	Over-broad permissions, PII in logs, screenshot caching, clipboard leakage
M7	Insufficient Binary Protections	No obfuscation, missing anti-tamper, no root/jailbreak detection, debugger attaches
M8	Security Misconfiguration	Debug builds in production, exported activities, world-readable storage, weak ATS exceptions
M9	Insecure Data Storage	Tokens in SharedPreferences/UserDefaults, plaintext databases, sensitive data in backups
M10	Insufficient Cryptography	Hardcoded keys, weak ciphers (ECB/MD5), platform keystore bypass, weak random

---

M1 — Improper Credential Usage

What it is

The mobile binary contains credentials — an API key, a third-party SDK key, a private key for signing, or a hardcoded admin password — that an attacker can recover by unzipping the APK / IPA and grep'ing strings. Or the credentials are derived from a predictable input (username + a constant salt) and an attacker can reproduce them offline.

Why it matters

Mobile binaries are public. Every APK in the Play Store can be downloaded with gplaycli; every IPA on a jailbroken iPhone can be exported in seconds. Anything compiled into the binary is, for security purposes, published. We've seen production apps shipping AWS access keys, payment-gateway merchant keys, and even internal SSH credentials — recovered in under five minutes by a tester with no specialised tools.

Real-world impact

In our 2024–25 mobile engagements we recovered embedded credentials in 1 of every 3 unsigned-NDA assessments. The typical exposure:

• Backend-API keys that bypass the gateway's auth layer.
• Cloud-storage keys (S3, GCS) granting read or write on customer-PII buckets.
• Payment-aggregator keys (Razorpay, Cashfree, PayU) — straight financial loss.

What your team should fix

• Never embed long-lived credentials in the app binary. Tokens must be exchanged at runtime from a user-authenticated session.
• Use mobile attestation (Play Integrity API on Android, App Attest on iOS) to ensure your backend only honours requests from an unmodified copy of your app.
• Rotate any credential ever shipped in a binary — assume disclosure. Audit the last 5 versions of your APK/IPA for accidentally committed keys.

---

M2 — Inadequate Supply Chain Security

What it is

Your app is not just your code — it's also every SDK you embed (analytics, advertising, crash reporting, payments, push notifications, social SDKs). Each of those is a third-party module that ships into production with the same trust your code has. If one of them is compromised, malicious, or simply low-quality, the whole app inherits the problem.

Why it matters

The mobile SDK ecosystem has had repeated compromise incidents — XcodeGhost (2015), the SourMint / Mintegral SDK (2020), and several ad SDKs that quietly exfiltrated user data through 2023. A typical Indian fintech app integrates 15–25 third-party SDKs; few teams audit them.

What your team should fix

• Maintain an SDK inventory with version, license, and last-audited date.
• Pin SDK versions in your Gradle / Podfile and review every minor update for behavioural change.
• Block tracking SDKs at runtime if they exceed declared permissions or attempt to read sensitive APIs (clipboard, IMEI, contacts).
• Verify update channels — if your app downloads runtime configuration, signed-blob validation is non-negotiable.

---

M3 — Insecure Authentication / Authorization

What it is

Anything that's wrong about who is making the request and what they are allowed to do. In mobile this hits in several distinct ways:

• The local biometric prompt is the only auth — bypass biometric, you're in.
• OAuth tokens are issued with overly broad scopes or never expire.
• Server-side authorization is missing — the API trusts a userId or accountNumber sent from the client.
• Session tokens persist after logout / app uninstall.

Why it matters

Authentication failures account for the majority of high-severity findings in mobile engagements — both because authn/authz is easy to test and because the impact (account takeover, transaction fraud, data theft) is immediate.

What your team should fix

• Treat biometric prompt as a UX layer, not an auth layer. The session token comes from a real authentication on the server.
• Reject any client-supplied identifier in privileged endpoints. The user is who the session token says they are.
• Use short-lived access tokens (≤15 min) with refresh-token rotation. Bind refresh tokens to device fingerprints when possible.
• Verify session state server-side on every privileged action — never trust client state.

---

M4 — Insufficient Input / Output Validation

What it is

The mobile equivalent of injection. Three big surfaces:

• WebView — JavaScript bridges, loadDataWithBaseURL, file:// URL handling. SQL/JS injection from server responses or deeplinks.
• Deeplinks / app links — URL parameters that feed directly into intents, file paths, or WebView loads without validation.
• IPC — Android intents and iOS extensions that accept untrusted input and act on it (file write, payment trigger).

Why it matters

A deeplink XSS in a banking app's WebView is functionally equivalent to a web XSS — except the mobile session is typically longer-lived and has access to platform APIs (contacts, location).

What your team should fix

• Disable JavaScript in WebViews unless mandatory; if mandatory, restrict the addJavascriptInterface surface to a single audited method.
• Validate all deeplink parameters before passing to UI / network / file APIs.
• Treat IPC inputs as hostile — explicitly check the calling package and validate every field.
• Whitelist allowed origins for WebView page loads.

---

M5 — Insecure Communication

What it is

Anything that lets a network attacker intercept, modify, or replay traffic between the app and your backend:

• No TLS, or TLS only on some endpoints.
• TLS without certificate pinning — easy to MITM with a user-trusted root CA installed.
• Trusting self-signed certificates in production.
• Plain-HTTP fallback if HTTPS fails.

Why it matters

Public Wi-Fi, hotel networks, corporate proxies, and state-sponsored CA fraud are all real threat models. The 2024 OWASP Mobile Top 10 treats TLS pinning as mandatory for any app handling regulated data (financial, health, government).

What your team should fix

• Pin certificates or public keys for all backend API endpoints. Use Network Security Config on Android, App Transport Security exceptions reviewed manually on iOS.
• Disable user-trusted CAs in production builds via trustUserCerts="false" (Android) — prevents most MITM-with-installed-cert attacks.
• No HTTP fallback. If TLS is unavailable, the request fails closed.
• Test pinning under real MITM — Frida, mitmproxy, Burp + Magisk module. If a tester can intercept the traffic, so can an attacker.

---

M6 — Inadequate Privacy Controls

What it is

The app collects, retains, or exposes more user data than its stated purpose justifies:

• Permissions broader than needed (microphone always-on for a delivery app).
• PII logged to local files or external crash reporters.
• Screenshots cached in the recent-apps view exposing balances or credentials.
• Clipboard data read on every foreground.

Why it matters

DPDP Act (effective 2024 in India) puts privacy controls on the same footing as security controls. RBI's Digital Lending Guidelines explicitly require minimum-permission design. SEBI's CSCRF (for capital-market REs) mandates data localisation and minimisation.

What your team should fix

• Audit the AndroidManifest / Info.plist permissions list. Remove anything not actively used.
• Mark screens with sensitive data with FLAG_SECURE (Android) / hide content during transitions to recent-apps (iOS).
• Disable verbose logging in release builds. Crash reporters strip PII before transmission.
• Don't read clipboard on foreground. iOS shows a banner — users notice.

---

M7 — Insufficient Binary Protections

What it is

The mobile binary lacks defences against reverse engineering, instrumentation, and tampering:

• No code obfuscation — class and method names readable in the APK.
• No anti-debug — attaching Frida or LLDB is trivial.
• No root / jailbreak detection — or detection that's easy to bypass.
• No integrity checks — modified binaries run identically to the original.

Why it matters

Binary protections raise the cost of attack but do not eliminate it. The justification is time — for any app with significant financial or regulated value, you want an attacker to spend days breaking into your binary rather than minutes. That window is when fraud teams detect anomalous behaviour.

What your team should fix

• Enable R8 / ProGuard with aggressive optimisation on Android. Strip debug symbols and use bitcode where supported on iOS.
• Layer anti-debug + anti-Frida checks — multiple independent detections at different points in the lifecycle.
• Implement root / jailbreak detection using attested signals (Play Integrity, App Attest) rather than easily-spoofed client checks.
• Validate binary integrity at runtime — checksum your own DEX / Mach-O segments and refuse to run if modified.

---

M8 — Security Misconfiguration

What it is

Sensible defaults disabled or insecure defaults left on:

• Debug builds shipped to production.
• Exported Android activities that should be private.
• World-readable internal storage.
• Backup flags allowing the app's data to be extracted via adb.
• ATS (App Transport Security) exception domains added "just for testing" and never removed.

Why it matters

Misconfigurations are the easiest class of finding to fix and the most embarrassing to ship — they signal that no one ran a static analyser before release.

What your team should fix

• Strip android:debuggable="true" and allowBackup="true" in release manifests.
• Audit exported components — every <activity android:exported="true"> should have a justification.
• Remove ATS exceptions before the production release. If a partner endpoint isn't HTTPS, fix the partner.
• Run MobSF or equivalent in CI on every release candidate — fail the build on debug flags.

---

M9 — Insecure Data Storage

What it is

Sensitive data is written to a location that other apps, ADB, or backups can read:

• Session tokens in SharedPreferences / UserDefaults.
• Database files with no encryption.
• Sensitive data in plain-text JSON cache files.
• Backups (@xml/backup_rules, iCloud) including private databases.

Why it matters

Mobile data at rest is data on a device the user controls — and that device may be lost, sold, jailbroken, or owned by malware. Anything sensitive must survive that threat model.

What your team should fix

• Don't store long-lived secrets locally. Re-fetch on each app launch with an authenticated request.
• For anything that must persist (offline tokens, cached PII), use AndroidKeyStore / iOS Keychain for keys and encrypted databases (SQLCipher, Realm encrypted) for content.
• Exclude sensitive paths from backups — android:fullBackupContent rules + Data Protection class on iOS.
• Wipe on logout — explicit delete of cached files and stored credentials, not just session token invalidation.

---

M10 — Insufficient Cryptography

What it is

Weak crypto primitives, misuse of strong primitives, or hardcoded keys:

• DES, RC4, MD5, SHA-1 — broken for years, still in production apps.
• AES-ECB — leaks structure, not semantically secure.
• Hardcoded AES keys in the binary (often paired with M1).
• Random() instead of SecureRandom() for IVs or tokens.
• Custom crypto implementations.

Why it matters

The strength of an app's data protection caps at the strength of its weakest crypto primitive. Detecting this on a binary is one of the first things a tester does — and one of the easiest to weaponise once found.

What your team should fix

• Use platform crypto APIs — Cipher (Android, with AES/GCM/NoPadding), CryptoKit / CommonCrypto (iOS). Don't roll your own.
• Derive keys from authenticated user input (passcode + KDF like Argon2 / scrypt) rather than embedding them.
• Use SecureRandom / SecRandomCopyBytes for any cryptographic randomness.
• Audit every Cipher.getInstance(...) call in CI for forbidden algorithms.

---

How this maps to your testing programme

A meaningful mobile pentest covers every line item in this list — not as a checklist but as a threat model. Skipping a category because "we have it covered" is how the 1-in-3 hardcoded-credentials statistic above happens.

For Indian regulated entities, the cadence we recommend:

• BFSI / Fintech (RBI-regulated): mobile pentest before every major release, full annual VAPT, plus a quarterly delta-scan on new SDK integrations.
• SEBI CSCRF entities: annual mobile pentest is recommendatory under the Aug 2025 clarifications — but for any market-facing app (trading, demat, AIF reporting) we recommend treating it as mandatory.
• IRDAI / health insurance: mobile pentest on every release that touches policy purchase or claims data — these have direct PII exposure.

The OWASP Mobile Top 10 is the floor, not the ceiling. A complete assessment also covers business-logic flaws (referral abuse, coupon stacking, KYC bypass), platform-specific issues (App Clip / Instant App scope), and observability gaps that prevent fraud detection.

---

What good looks like

In our experience, mobile-security maturity has four levels:

1. Reactive — pentest on regulator demand, mostly findings deferred. Most teams start here.
2. Annual — mobile pentest before annual filing, CERT-In submission. Findings tracked but rarely retested.
3. Release-gated — mobile security is part of the release checklist. New SDKs reviewed. Retest after fix.
4. Continuous — SAST in CI, dependency scanning on every commit, quarterly pentests, runtime telemetry for anomalous binary behaviour.

For regulated entities the realistic target in 2026 is level 3 — release-gated mobile security with quarterly external validation.

---

Next step

If you're shipping a mobile app to Indian consumers — and especially if you're regulated by RBI, SEBI, or IRDAI — the OWASP Mobile Top 10 is the minimum bar you should be testing against. Our Mobile Application Security Testing service covers every entry in this list plus business-logic, platform-specific, and supply-chain testing.

Talk to our mobile security team →