The OWASP list enumerates the most serious risk categories in web applications, published by the OWASP Foundation and labelled with category identifiers rather than bug names. One practical consequence follows: the list is not tested item by item but used as a review criterion for architecture, permissions and dependencies.
Quick Overview
What you’ll learn:
- How a risk category differs from an individual vulnerability
- Why a scanner cannot certify conformance with the OWASP list
- What order to adopt controls in so you do not start at the end
- Where to place testing in delivery so it is not a one-off exercise
Who this article is for:
- Teams building and maintaining web applications
- Technical leads and product owners accountable for release quality
- People scoping a security audit before commissioning it externally
Reading time: 7 minutes
A Risk Category Is Not a Vulnerability
The most common misunderstanding concerns the nature of the list itself. The owasp.org compilation groups risk into categories labelled in the form A01:2025, not into individual implementation defects. The A01:2025 category (broken access control) covers a missing authorisation check on an endpoint, the ability to swap an identifier in a request, and a leak of another user’s data through a careless filter.
A vulnerability is concrete: it has a location in code, a severity expressed on the CVSS scale and a defect class in the CWE dictionary. A category is a question about a mechanism. That is why a scanner report listing discovered vulnerabilities does not answer whether the application handles a given risk category — it answers only whether the tool found examples.
This distinction shapes the conversation with an audit supplier. Scope described as “verify OWASP conformance” is unverifiable. Scope described as “review API access control, verify session management, analyse dependencies” has a boundary and can be accepted on delivery.
Why a Scanner Is Not Enough
Static and dynamic tooling have disjoint strengths. Static analysis sees patterns in code, including paths no test reached, but it does not know which of them are reachable in a running application. Dynamic analysis works against a live service, so it observes real behaviour, yet it never reaches functions hidden behind authorisation logic. Dependency composition analysis finds components with publicly known vulnerabilities that neither of the former assesses correctly.
The testing guide on owasp.org arranges these activities in sequence and states what counts as evidence at each step. For a delivery team the useful conclusion is counter-intuitive: the categories hardest to automate concern business logic and permissions — exactly what tooling has no model of. There, the evidence is a review performed by a person with access to the requirements.
Then there is regression. A category closed once reopens with every change to the permission model or every new role added. A single audit therefore attests to the state on the day of testing, not to a property of the application.
An Adoption Order That Does Not Start at the End
Teams usually start by buying a tool, and that is the third step rather than the first. The order that works looks different:
- A permission model written down outside the code — who may access what, and on what basis. Without that document there is no way to state whether access control is broken, because there is no reference point.
- A dependency and version register — so that a question about a component with a publicly known vulnerability has an addressee and a deadline.
- Automation in the release pipeline — code and dependency scanning on every change, with a threshold that blocks a release.
- Human review for business logic — on a cycle, and after every change to access rules.
The csrc.nist.gov document SP 800-218 describes this arrangement as development practices: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. The practice names are useful in board conversations because they move the discussion from tools to a process somebody has to own.
Where Testing Belongs in Delivery
Security testing placed only before a production release is an acceptance test, and it almost always arrives too late to redesign anything. Placed only in an automated pipeline, it guards against regression but will never find a missing control that was never designed.
The arrangement that holds up in delivery teams spreads the work across distinct moments: threat modelling when a new feature is designed, automated scanning on every merge, and a permission review whenever a role or an integration changes. The first moment is the cheapest and the most often skipped, because it produces no report — it produces a design decision.
Verification depth is worth agreeing explicitly as well. The owasp.org verification standard describes graded levels of requirements, which lets a team state how deeply a given application is to be checked instead of arguing about whether a report is “complete”. Ownership matters just as much: an application security engineer runs the method and challenges findings, while the decision to ship with an open vulnerability belongs to the product owner.
Read Also
- OWASP Top 10 Risk by Risk: A Guide for IT Leaders — the category-by-category walkthrough, useful when building audit scope
- Penetration Testing: Where to Start as a Company — what an external engagement delivers and how to read its report
- Threat hunting: proactively finding threats — what to do about what a scan and a code review did not show: looking for traces in the application already running
Build Your Skills
This topic is developed in the OWASP — comprehensive security testing of web applications and OWASP Top 10 — key application security threats courses. The first is a hands-on testing workshop, the second a category review for a delivery team. Contact us to match the scope to your team’s technology stack.
Frequently Asked Questions (FAQ)
Is the OWASP list a set of vulnerabilities to test against?
No. These are risk categories, each covering many distinct implementation defects. What gets tested are specific application mechanisms — access control, session management, input validation, dependency handling — while the category serves to check that the review forgot none of them.
How does an application security audit differ from vulnerability scanning?
In the scope of the evidence. Scanning is a tooling activity and yields findings with a location in code or in a request. An audit also covers mechanisms no tool assesses: the permission model, business logic, data flow across integrations. Scanning is often part of an audit; it does not replace one.
Which edition of the list is current, and does the category numbering change?
A category identifier carries its edition year, so the current owasp.org list uses labels in the form A01:2025 while the previous one used A01:2021. Numbering and category content change between editions, so audit scope should name a specific edition for reports to stay comparable over time.
Where should an in-house team start with web application testing?
With the permission model and the dependency register, because without them results have no reference point. Pipeline automation comes next, and commissioning an external test comes last — an outside team prices reconnaissance work higher when it has to do that groundwork for you.