Why it matters
Teams, testers and buyers need a common language. When a tester says broken access control or injection, everyone knows the kind of flaw meant. The list is built from data on real vulnerabilities and from expert opinion, and OWASP updates it every few years as attacks change.
What is on it
The categories change between editions, but the themes are steady. Recurring ones include the following.
- Broken access control: users act outside their permissions, for example by changing an ID in a URL.
- Cryptographic failures: weak or missing protection for data in transit or at rest.
- Injection: untrusted input is run as a command or a query, as in SQL injection. Cross-site scripting is a kind of injection too.
- Insecure design: the plan itself lacks a needed control, which threat modelling is meant to catch.
- Security misconfiguration: unsafe defaults, open services and missing headers.
- Vulnerable and outdated components: libraries with known flaws.
- Authentication failures: weak sign-in, or no multi-factor authentication where it is needed.
How teams use it
Use it to shape training, code review checklists and test plans. For a detailed list of requirements to verify against, OWASP offers the Application Security Verification Standard (ASVS). Treat the Top 10 as a floor, not a ceiling: an app can avoid every item and still have a serious flaw in its own logic.
Common mistakes
- Treating we covered the Top 10 as meaning we are secure.
- Reading it as a list of separate tasks instead of a prompt to ask what could go wrong in your own product.
- Using an old edition without checking for the latest one.
Related terms
Findings from a penetration test are often mapped to these categories. Our secure by default web checklist is a practical place to start.