The OWASP Mobile Top 10 is a list of the ten most common classes of mobile app weakness, last revised in 2024. Read through a fraud lens, it becomes a map of where fraudsters get their foothold: a key left in the package, a binary that can be modified, traffic that can be read, a login that trusts whatever the device says. This article walks through the attack behaviour behind each risk, what an app can and cannot see, and how Otukan maps each risk to a control on Android and iOS. For turning industry index findings into a code and binary protection test of your own app, see mobile security index analysis.
The 2024 list at a glance
| Risk | Name | What a fraudster gets |
|---|---|---|
| M1 | Improper credential usage | API keys and tokens to call your backend directly |
| M2 | Inadequate supply chain security | A compromised SDK or build step inside a trusted app |
| M3 | Insecure authentication and authorisation | Actions that the server allows without proper checks |
| M4 | Insufficient input and output validation | Injection into app logic or the backend |
| M5 | Insecure communication | Readable or modifiable traffic |
| M6 | Inadequate privacy controls | Personal data to support impersonation |
| M7 | Insufficient binary protections | An app that can be read, modified and repackaged |
| M8 | Security misconfiguration | Debug features, exported components, loose permissions |
| M9 | Insecure data storage | Tokens and data readable on the device |
| M10 | Insufficient cryptography | Data that looks protected but is not |
- 2016
OWASP Mobile Top 10 (2016)
The long-standing edition most security reviews still reference.
- 2024
OWASP Mobile Top 10 (2024)
A revised list that adds supply chain security and privacy controls, and names binary protections explicitly.
Attack behaviour: how fraud chains use the risks
Fraud rarely uses a single weakness. A typical account-takeover chain on a banking app strings three of them together.
Read the app
Decompile the package; find endpoints and a hard-coded key (M1, M7).
Script the API
Call login and transfer endpoints from a bot, outside the app (M3).
Reuse a session
Lift a token from a compromised device and replay it (M9).
Evidence with each request
Attestation and runtime signals travel with login and payment calls.
Backend decides
Your risk engine steps up or refuses the request.
Where Otukan maps each risk
Otukan groups its application security controls into five layers. The table below shows where each 2024 risk lands.
| Risk | Code | Runtime | Data | Network | API |
|---|---|---|---|---|---|
| M1 Credential usage | Secrets kept out of the package | Keys verified server-side | |||
| M2 Supply chain | Integrity of shipped code | SDK behaviour watched at run time | |||
| M3 Authentication | Hooked sign-in detected | Requests carry app evidence | |||
| M5 Communication | Hardened transport | ||||
| M6 Privacy | Sensitive data kept out of logs and screenshots | ||||
| M7 Binary protections | Obfuscation, anti-tampering | RASP | |||
| M8 Misconfiguration | Release build checks | ||||
| M9 Data storage | Keystore and Keychain use | ||||
| M10 Cryptography | Platform cryptography |
Counts come from the mapping table above. M4 (input and output validation) is a secure-coding responsibility and sits outside the five layers.
Detection limits: what the app can see
An app sees its own process, its own package and what the operating system tells it. That is a lot, and it is not everything.
Visible to the app
- Hooking and debugging of its own process
- Changes to its own code, resources and signature
- Rooted or jailbroken environments, emulators
- Screen capture and overlays during sensitive steps
Needs the backend or other sources
- Whether a request came from the app at all
- Whether a token is being replayed elsewhere
- Account history and transaction patterns
- Confirmation that an incident really happened
On Android and iOS the visible set differs. Android exposes more about installed software and system state; iOS keeps each app in a stricter sandbox, so signals focus on the app’s own process and on Apple’s attestation service. Otukan builds each check for its platform and never carries an assumption from one to the other.
Response: proportionate controls for real users
Treat each risk as a question for a specific user flow: what should happen at login, at payee creation, at transfer, when the signal fires?
- Observe first. Send signals to your backend without changing the experience and measure how often each fires.
- Step up where it matters. Ask for a second factor or a confirmation on high-value actions when signals combine.
- Restrict, then terminate. Pause sensitive features before ending a session, and give support teams a clear path for genuine users.
Before your next review
- Map your last penetration test findings to the 2024 risk numbers.
- List every secret shipped in the package, and move each one server-side.
- Check which API calls your backend accepts without app evidence.
- Decide the response for each signal on login, payee creation and transfer.
- Test the protected build on your oldest and newest supported devices.