Walk through the OWASP Mobile Top 10 — which ones matter most for a typical consumer app?
The list isn't ranked by severity — the senior move is mapping its ten categories onto your own app's actual data and attacker.
LEARN BY DOINGPut your intuition to work3 steps
Walk through the OWASP Mobile Top 10 — which ones matter most for a typical consumer app?
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.#What the list actually is
The OWASP Mobile Top 10 is a categorization of common mobile risk areas, refreshed by the OWASP Mobile Security team to reflect how apps are actually built and attacked today — heavier on backend-adjacent risk (auth, supply chain, privacy) than the original 2016 edition, which leaned more on client-side code quality. It is explicitly not ranked by severity: M1 is not "worse" than M10 for every app, it's just first alphabetically-by-category in the current numbering. Interviewers who ask you to "walk through it" are rarely testing memorization of the exact wording — they're testing whether you can use it as a checklist to structure a threat-modeling conversation and then reason about which categories actually bite for the app in front of you.
Here's the current set, in a sentence each:
- M1 — Improper Credential Usage. Hardcoded secrets, tokens stored insecurely or kept alive far longer than needed, and weak handling of the credentials an app collects or forwards.
- M2 — Inadequate Supply Chain Security. Risk introduced by third-party SDKs, build tooling, and dependencies you didn't write — a compromised analytics SDK is this category.
- M3 — Insecure Authentication/Authorization. Client-side-only checks, weak session handling, and backend authorization gaps (IDOR-style issues) that a mobile API surface happens to expose.
- M4 — Insufficient Input/Output Validation. Trusting data from the network, deep links, intents, or clipboard without validating it before acting on it.
- M5 — Insecure Communication. Cleartext traffic, disabled or downgraded certificate validation, and third-party SDKs phoning home over plain HTTP.
- M6 — Inadequate Privacy Controls. Collecting, retaining, or sharing more personal data than the feature needs, or without the consent the platform (and regulation) requires.
- M7 — Insufficient Binary Protections. Weak resistance to reverse engineering, tampering, and repackaging of the client binary itself.
- M8 — Security Misconfiguration. Debuggable release builds, exported components with no permission checks, verbose error messages, permissive backup rules.
- M9 — Insecure Data Storage. Tokens, PII, or cached responses sitting unencrypted in shared preferences,
UserDefaults, logs, or backups. - M10 — Insufficient Cryptography. Weak algorithms, home-grown crypto, or correct algorithms used incorrectly (reused IVs, ECB mode, keys derived from predictable material).
#Which ones actually matter for a typical consumer app
Not all ten carry equal weight for, say, a social or e-commerce app without payment-card handling or DRM concerns. In rough order of how often they show up:
M9 (Insecure Data Storage) is close to universal — almost every app persists a session token, some cached user data, or crash-report breadcrumbs, and plaintext SharedPreferences/UserDefaults is still the most common way that data leaks on a lost or shared device. M5 (Insecure Communication) is right behind it: cleartext traffic left over from a debug build, or a certificate-validation shortcut added "temporarily" for a staging environment and never removed, are extremely common findings. M1 (Improper Credential Usage) shows up constantly as hardcoded API keys committed to the client and tokens that never expire. M3 (Insecure Authentication/Authorization) matters as soon as an app has more than a login screen — most of the actual damage tends to live on the backend the mobile client talks to, but the mobile app is often how the gap gets discovered. And M2 (Inadequate Supply Chain Security) deserves more attention than it usually gets: a typical consumer app embeds a dozen-plus SDKs for ads, analytics, and crash reporting, each one a dependency you didn't audit and a vector you don't fully control.
By contrast, M7 (Insufficient Binary Protections) and M10 (Insufficient Cryptography) matter enormously for a banking app, a DRM-gated video player, or an anti-cheat system, and much less for a to-do list app that has no client-side logic worth tampering with. M6 (Inadequate Privacy Controls) sits in between — it's increasingly forced on every app regardless of threat model by App Tracking Transparency, Play Data Safety labels, and GDPR/CCPA, so it shows up as a compliance requirement even where it isn't a juicy attack target.
#How to actually answer this in an interview
The weak answer recites all ten evenly, as if they were equally likely and equally severe for every app. The strong answer picks three or four, explicitly ties each to a concrete mechanism ("M9 because our refresh token sat in plain SharedPreferences until we moved it behind EncryptedSharedPreferences," not just "insecure storage is bad"), and explains why those rank higher than the rest for this specific app's data sensitivity and attacker motivation. That's the same skill as reading a codebase and knowing which anti-pattern is worth a PR comment versus which one is stylistic noise — prioritization under a threat model, not category recall.
🧠 OWASP Mobile Top 10
0/3 · 0/3 answered1. Is the OWASP Mobile Top 10 ordered by severity, from most to least critical?
2. For a typical consumer app (not a banking or DRM app), which pairing is most immediately relevant?
3. A third-party analytics SDK your app embeds gets compromised upstream and starts exfiltrating data. Which category best captures this risk before it happens?