OWASP Top 10
In application security, the OWASP Top 10 is a periodically updated awareness document listing the categories of web application weakness that the project considers most important. It is a set of categories to be aware of, published by a non-profit foundation. It is not a standard, a certification, or a test scope.
How it works
The Open Worldwide Application Security Project assembles the list from contributed vulnerability data and a practitioner survey, groups findings into broad categories rather than individual bugs, and republishes it every few years. Each entry describes a class such as broken access control or injection, with example scenarios and prevention guidance, and maps to the underlying weakness enumeration so a finding can be tied to a specific defect type.
The value is shared vocabulary. When a report says broken access control, a developer, a security lead and an auditor all understand roughly the same thing, and the mapping means the category can be traced to a precise weakness identifier when precision is needed.
What goes wrong
The recurring problem is not the document. It is what people do with it in a procurement conversation. Three misreadings show up repeatedly.
It is treated as a scope. A test that covers ten categories and stops has not tested the application: business logic flaws alone will not appear in any list of generic categories, because they are specific to the system under test. It is treated as a standard to be compliant with, which the project itself does not claim; when a control standard is wanted, the application verification standard from the same project is the document that was designed for that job. And it is treated as a ranking of risk in your estate, when it is a ranking of prevalence across contributed data from many estates, which is not the same question.
The second-order effect is worse. A scanner that reports coverage of the ten categories can be technically accurate and still leave an application with an unauthenticated route to another tenant’s data, because the coverage claim is about categories, not about your access control model. The same caution applies to the separate API list.
Where this shows up in an audit
We map every finding to a category so the report can be compared with previous work and with a scanner’s output, and then we say plainly which findings had no category to sit in. Statements of work that name the ten categories as the scope are worth renegotiating before the test rather than after. Confirm the current edition before quoting it, since the categories are renamed and merged between releases. This is part of what a full web application assessment actually covers.