Use the release label accurately
The official OWASP release source distinguishes the 2024 list from historical 2016 material. References to older category numbers must include their year. The same number can refer to a different risk in another edition.
Rather than copying the list into an issue tracker and marking every heading complete, translate the relevant risks into tests for your application.
Translate risks into product questions
| Review theme | Practical Android question |
|---|---|
| Credentials and authentication | Are long-lived secrets embedded in the client, and can sessions be revoked? |
| Supply chain | Which resolved SDK versions actually ship? |
| Input handling | Are imported files, links and server responses validated at the boundary? |
| Communication | Does every sensitive client path use the intended trust rules? |
| Privacy and storage | Does collection match disclosure, and where does sensitive data persist? |
| Binary configuration | Did debug-only flags or diagnostic capabilities reach the release? |
This table is an editorial test worksheet, not an official replacement ranking or an exhaustive reproduction of OWASP's categories.
Avoid ranking-based blind spots
A risk absent from a short awareness list can still be critical to your product. For example, an app's unusual account-recovery workflow or a proprietary device interface may deserve tests that a generic checklist does not suggest.
Likewise, obfuscating the binary cannot compensate for a backend that accepts unauthorized requests. Prioritize failed trust boundaries and sensitive data exposure, not just findings that are easy to eliminate from a static report.
Add a control and test framework
Use MASVS to describe the controls you expect and MASTG to select procedures. Document applicable areas, evidence, exclusions and the exact app version. That creates a review someone can reproduce, rather than a marketing statement that the app is “Top 10 compliant.”
Use APKLint as triage
APKLint's OWASP resource helps organize static checks around manifest, transport and package observations. Treat it as the starting inventory. A full assessment also needs runtime behavior, server-side authorization and the actual data flows of included SDKs.
Use a risk theme to ask a feature-specific question
In a planning session for a delivery app, a privacy theme can lead to a concrete question: does the diagnostic event include the customer's full address when a coarse delivery region would be enough? Identify the event owner and the actual payload. The useful output is an inspectable data flow, not a ticket that merely repeats a risk-category title.
The Mobile Top 10 project provides risk-awareness material. Record the edition used when discussing a category. Keep the team's worksheet visibly separate from the official list so readers do not mistake an adapted prioritization exercise for OWASP's own ranking.
Choose a test and a measurable repair
Exercise the delivery failure with synthetic addresses and inspect the application-owned diagnostic payload. If it contains unnecessary address data, identify the construction path and remove or reduce the field according to the feature's need. Repeat both a successful delivery and a failed delivery; the failure branch can collect more information than the ordinary path.
Check whether the same field is copied into crash attributes, support exports or queued retries. These are related data paths that can preserve the exposure after the first event is repaired. Record which surfaces were examined and which require a separate owner or test environment.
Use a control framework and test procedures to make the review reproducible. A risk theme helps explain priority, but the acceptance condition should name the field, destination and observed behavior. For example, the repaired diagnostic event can retain the non-sensitive failure code while omitting the full synthetic address.
Compare this issue with other findings using impact and exposure, not category position alone. A broken account authorization boundary may deserve attention before a low-impact hardening concern even if both fit broad awareness headings. Keep the rationale with the review so priorities can change when the product or threat model changes.
When reporting completion, identify the tested feature and repaired data flow. Avoid a blanket statement that the application passes the Top 10. An awareness list can organize useful work, but only evidence from the actual implementation supports a claim about that implementation.
Sources and further reading
- OWASP Mobile Top 10 — official release source
- OWASP: Mobile Application Security Verification Standard
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
