What Is OWASP Top 10?

The OWASP Top Ten is a periodically updated list of the most significant web application security risks, compiled from contributed data and practitioner survey. It is the most widely referenced document in application security.

It is an awareness document. It describes categories of risk rather than a checklist of tests, and treating it as a standard is the most common way it is misused.

What it is useful for

Communicating priorities to development teams who do not work in security full time. Structuring training. Providing a shared vocabulary between developers, testers and security staff.

It is also a reasonable minimum bar for a security requirement in a contract or a policy — not because it is comprehensive, but because an application with serious issues in these categories has not had meaningful attention.

What it is not

Not a complete list of application vulnerabilities. Not a testing methodology. Not a compliance standard, despite being cited as one in a great many contracts.

An application can be free of issues in all ten categories and still be badly insecure, because business logic flaws — which are frequently the most damaging — are largely outside its scope.

The categories have shifted meaningfully

Recent revisions have moved toward broader groupings and toward design-level concerns rather than specific implementation bugs. Broken access control has risen to the top, reflecting what testers actually find.

Injection, historically the headline risk, has fallen as frameworks made parameterised queries the default — which is the general lesson: the categories move when tooling makes a mistake harder to commit.

Using it in a development process

The useful application is preventive rather than assessive: framework choices that make these categories hard to commit, code review focused on the relevant patterns, automated testing integrated into the pipeline, and developer training organised around the categories.

Checking an application against the list after it is built finds problems late, when they are expensive. The same ten categories used as design guidance cost almost nothing.

The companion lists

Separate lists exist for interfaces, mobile applications and large language model applications, each addressing risks the main list does not cover well. The interface-focused one matters particularly, since a large share of modern applications are primarily interfaces with a thin client.

Checking whether a companion list fits your architecture better than the main one is worth a few minutes.

The verification standard is the companion document

Where a genuine checklist is needed, the same organisation publishes an application security verification standard — a structured set of requirements at several assurance levels, designed for exactly the purpose the Top Ten is repeatedly misused for.

It is considerably longer and far more useful as a contractual or testing reference, because it states verifiable requirements rather than risk categories. Citing it in place of the Top Ten resolves most of the ambiguity that appears in procurement language.

Where to start

Take the top category, broken access control, and check how your main application enforces authorisation on server-side requests. It is where the most findings are, and it is rarely tested systematically.

See common findings in penetration tests. GuardsArm delivers application penetration testing.