Use Cases · Knowledge base
Mobile application security case library
A growing library of representative mobile app security cases. Each entry is mapped to the OWASP Mobile Top 10 and documented by the Mobexa research team with the finding, its business impact and a remediation path. Select any case to read the full write-up.
This library collects anonymised, representative cases drawn from mobile application security research. Every case describes a class of weakness we see in real, publicly distributed apps - what it is, why it matters to a business, how Mobexa detects it, and how to fix it - without naming any product, company or vendor.
New cases are published here regularly. The table below is the full index: filter by keyword or severity, then open a case for the detailed article.
1 Overview
Mobile apps fail in recognisable patterns. A credential that belongs on a server gets shipped inside the binary; a third-party component goes unpatched; a token is written to disk in clear text; transport security is quietly switched off. Individually these are simple mistakes, but each can expose an entire user base at once.
The cases below are framed against the OWASP Mobile Top 10 (2024) so they map cleanly to a recognised standard. They are written for a security-aware reader who wants to understand the weakness, judge its impact, and know what a fix looks like.
These cases are anonymised and generalised for education. They do not identify any specific application, company or individual, and the figures cited reflect industry research current in 2026.
2 Case index
Every documented case, newest research first. Use the filter to narrow by keyword, OWASP code, platform or severity.
| ID | Case | OWASP | Severity | Platform | Updated |
|---|---|---|---|---|---|
| UC-01 | Exposed push notification server key Mass unauthorised push to the entire install base | M1 | Critical | Android | May 2026 |
| UC-02 | Vulnerable bundled component Exploit inherited from an unpatched dependency | M2 | High | Cross-platform | May 2026 |
| UC-03 | Clear-text auth token at rest Account takeover from a shared or backed-up device | M9 | High | Android | April 2026 |
| UC-04 | Disabled certificate validation Interception and modification of all API traffic | M5 | High | Android | April 2026 |
| UC-05 | Hard-coded local encryption key Local encryption that is trivially reversible | M10 | High | Cross-platform | March 2026 |
| UC-06 | Over-exported app component Local data disclosure to a co-installed app | M8 | Medium | Android | March 2026 |
| UC-07 | Excessive data collection Privacy exposure and regulatory liability | M6 | Medium | Cross-platform | May 2026 |
| UC-08 | Deep link parameter injection Unvalidated input driving unintended actions | M4 | Medium | Android | February 2026 |
| UC-09 | Missing binary protections Repackaging, instrumentation and logic bypass | M7 | Medium | Android | February 2026 |
| UC-10 | OAuth client secret in binary Impersonation of the app identity to its provider | M1 | High | iOS | May 2026 |
| UC-11 | Broken object-level authorization Access to other users' records by changing an identifier | M3 | High | Cross-platform | April 2026 |
3 How these cases are prepared
Each case starts from analysis of publicly distributed application binaries. The Mobexa research team combines static review of the package - code, resources, manifests and bundled components - with dynamic analysis of the running app, including its network traffic and on-device storage. Findings are validated to remove false positives before they are written up.
Write-ups are deliberately vendor-neutral. We describe the class of weakness and its consequences rather than any single product, and where a real-world issue informs a case it is generalised so that no application, company or person can be identified. The aim is a durable reference, not a disclosure log.
4 See also
Maintained by the Mobexa research team. Cases are anonymised and provided for educational use; mappings reference the OWASP Mobile Top 10 (2024).