What the Top 10 is, and how to use it

The OWASP Top 10 is a document published by the Open Worldwide Application Security Project, a non profit community. It ranks broad categories of web application security risk, based on data contributed by security companies and a community survey. A new edition appears every few years; the most recent is the 2025 edition, which follows the widely used 2021 list.

What it is good for

• A shared vocabulary. When a security report says "broken access control", everyone knows the family of problem.
• Prioritisation. The categories reflect what is found most often and what causes the most harm in real applications.
• A training map. It is a sensible order in which to learn secure coding.

What it is not

• It is not a complete standard. For a full checklist of requirements, OWASP publishes the Application Security Verification Standard (ASVS).
• It is not a compliance guarantee. An application can avoid every category on paper and still have serious flaws in its business logic.
• It is not a list of individual bugs. Each category groups many related weaknesses, catalogued as CWE entries.

The categories at a glance

The 2025 edition keeps broken access control at the top. It brings security misconfiguration higher, adds software supply chain failures as a broader category than the older vulnerable components entry, and introduces mishandling of exceptional conditions, covering errors that fail open or leak information. Injection, cryptographic failures, insecure design, authentication failures, integrity failures and logging and alerting failures remain.

Do not memorise the numbers. Learn the patterns behind them.

A developer's approach

For each category, ask four questions about your own code:

1. Where could this happen in our application? Which endpoints, queries, templates or configuration files?
2. What does our framework already do? Most modern frameworks prevent common mistakes by default, if you do not switch the protection off.
3. What is our safe pattern? One agreed way to do the risky thing, such as one data access layer that always parameterises queries.
4. How do we keep it fixed? A unit test, an integration test or a static analysis rule that fails when someone reintroduces the problem.

The rest of this course answers those four questions, category by category, with code you can adapt.