OWASP Top 10: what it contains and how a test follows it

OWASP Top 10 is published by the OWASP foundation, the Open Worldwide Application Security Project, a nonprofit organization focused on application security. A new edition doesn’t come out on a fixed cycle but roughly every three to four years, once enough data from real applications has been collected. The previous edition is from 2021.

Categories are not picked by voting on what sounds dangerous. Most of them come from data on how often weaknesses occur across a large sample of applications, and some from a survey among specialists, so that risks which are hard to measure automatically still make the list. That is why the order changes between editions, and so do the names of the categories.

The 2025 edition contains ten categories labeled A01 to A10, ordered by severity and prevalence. These are not ten specific vulnerabilities but ten groups that individual findings get sorted into. A single category can therefore cover dozens of different flaws in one report. The order is neither alphabetical nor random: it reflects a combination of occurrence and impact.

• A01 Broken Access Control: a user reaches data or functions that aren’t theirs. Changing an identifier in the address can be enough to exploit it: no tool and no knowledge of the code needed.
• A02 Security Misconfiguration: default passwords, debug modes left on, open administration interfaces, missing headers. The code is fine, the environment isn’t.
• A03 Software Supply Chain Failures: the risk that arrives with libraries, packages, and the build process. An extension of the earlier category for vulnerable components.
• A04 Cryptographic Failures: weak or missing encryption, passwords stored without a salt, sensitive data sent in the clear.
• A05 Injection: input from a user ends up inside a query or a command. SQL injection and cross-site scripting both belong here.
• A06 Insecure Design: the flaw isn’t in the implementation but in how the feature was thought out. A test finds it; fixing the code doesn’t solve it.
• A07 Authentication Failures: weak login, bypassing the second factor, poor handling of sessions and password recovery.
• A08 Software or Data Integrity Failures: updates and data are accepted without verifying where they came from.
• A09 Security Logging & Alerting Failures: an attack happens and nobody finds out. Either there is no record, or nobody is looking at it.
• A10 Mishandling of Exceptional Conditions: on an error the application behaves unsafely, for example by revealing its internal structure or ending up in a permissive state.

OWASP Top 10 describes risks, not procedures. For none of the ten categories will you find instructions on what to verify it with, what requests to send, what to look for in the response, or when the test is finished. It is a map of the areas where things go wrong, not a list of steps.

In practice this means the sentence “test our application against OWASP Top 10” gives you a brief that can be neither met nor missed. Two vendors will do two different depths of work under it and both will be formally correct. The procedures are described by a different OWASP document, as the comparison of Top 10 and the WSTG testing guide explains.

The second trap runs the other way. Top 10 is deliberately short, so plenty of things that are genuinely exploited in applications don’t fit into it: business logic flaws, race conditions, bypassing limits, or abusing a legitimate feature in an unintended order. A check limited to ten categories is incomplete by design.

A category turns into a specific test in three steps: the category breaks down into verifiable requirements, those turn into testing procedures, and those into individual attempts against a specific feature of the application. The catalog of requirements comes from the ASVS standard, the procedures from the WSTG testing guide. Without that last step the category stays a label.

Take A01 as the example. The category says “broken access control.” A requirement from ASVS turns that into a verifiable statement: access to an object is checked on the server for every request. The testing procedure then prescribes trying another user’s identifier for every role and every object type, including where the interface shows no link at all.

On an application with three roles and twenty object types that adds up to several hundred individual attempts. This breakdown is where the effort of an engagement is decided, which is why it helps to know how categories turn into a specific test plan.

Three things change between editions: the order of the categories, their boundaries, and sometimes the names themselves. Moving a category up is not a reshuffle of a list, it is information that this type of flaw started to occur more often or with a heavier impact. It isn’t cosmetic because what gets tested first moves with the order.

The 2025 edition shows this in two specific shifts. Two categories appeared that the 2021 edition didn’t have, supply chain and handling of exceptional conditions, and the separate category for Server-Side Request Forgery, tenth in the 2021 edition, disappeared. SSRF hasn’t stopped being exploited, it moved under broken access control. Anyone looking for the old category in the new document won’t find it, even though the risk is still there.

In Czech the shift is even more visible. The last official Czech translation of Top 10 was made for the 2013 edition by the CSIRT.CZ team at the CZ.NIC association, and no edition has come out in Czech since. Anyone whose internal policy leans on the Czech text is working with categories the original stopped using twelve years ago.

The most common consequence for a company is a quiet one. An internal policy or a contract with a development vendor refers to “OWASP Top 10” without a year, the document moves on, and the two sides picture a different scope under the same sentence. A contract therefore needs the edition with its year, or a reference straight to specific requirements.

OWASP Top 10 applies to APIs and mobile applications only in part. The base list aims at web applications and many of its categories fit an interface, but an API has its own typical flaws that did not fit into the web ten. OWASP therefore publishes separate lists for individual areas.

For interfaces that is the Top 10 risks for APIs, whose latest edition is from 2023. Separate lists exist for mobile applications, which aim at weak spots different from the web, and for large language models. In every case the same holds: it is a survey of risks for a given area, not a testing methodology. Anyone ordering an API test should name the procedures in the brief, not just the list of risks.