Testing Guide
How We Test the OWASP Top 10
The OWASP Top 10 tells you which categories of failure matter. It does not tell you how to find them in your application. This guide covers how each category is actually tested, and why most of them cannot be found by a scanner.
- All ten categories, with the testing method for each
- Written from engagement practice, not the specification
- Every category links to how the finding gets fixed
The OWASP Top 10 is a categorisation of risk, not a test plan. It is frequently misread as a checklist, which produces the most common failure in application security: a report that confirms ten categories were considered without demonstrating that any of them were genuinely tested.
The distinction matters commercially. Two vendors can both claim OWASP Top 10 coverage, deliver reports of similar length, and have done work that differs by an order of magnitude. This guide exists so you can tell the difference — in our work or anyone else's.
The ten categories, and what testing each one requires
The 2021 revision reorganised the list around root causes rather than symptoms. That reorganisation is useful, because it groups failures by the kind of testing effort they demand.
Categories that require understanding your business logic
Broken access control, insecure design and authentication failures cannot be found without knowing what your application is supposed to do and who is supposed to be able to do it. There is no signature for "this user should not be able to approve their own refund". These categories consume the majority of engineer time in a competent engagement, and they are where the findings that actually matter tend to live.
Categories where tooling genuinely helps
Vulnerable components and parts of security misconfiguration are well served by automation. Dependency scanning and configuration analysis produce real results here, which is why a cheap scan-only assessment can look productive: it finds the category that automation is good at and stops.
Categories that need both
Injection, cryptographic failures, SSRF, integrity failures and logging gaps all have shallow variants a scanner will catch and deep variants it will not. Blind, second-order and chained cases require a human working through the application's behaviour.
Why the same category produces very different findings
Take injection. An automated scanner will reliably report a reflected parameter that echoes a quote character. What it will not find is a value stored in one request, processed by a background job four hours later, and concatenated into a query in a reporting service that no scanner ever reached. Both are injection. Only one requires someone to have understood your architecture.
This pattern repeats across the list, which is why we publish the testing method for each category rather than a claim of coverage.
How to read a report that claims OWASP coverage
- Ask which categories were tested manually and which were tooling-led — a competent tester will answer without hesitating
- Look for access control findings. A report on a role-based application with none is usually evidence of what was not tested
- Check whether findings were exploited or inferred. "Potentially vulnerable" means nobody confirmed it
- Look for chained findings. Real engagements produce them; scan exports never do
- Confirm the report names the roles and privilege levels covered, not just the URLs
Where to start
If you are preparing for an audit, the compliance testing guide explains how these categories map onto SOC 2, ISO 27001, PCI-DSS and HIPAA evidence requirements. If you are trying to understand what an engagement on your own application would involve, the web application testing page describes the process end to end.
Common questions
Is the OWASP Top 10 the same as a penetration test?
No. The OWASP Top 10 is a list of risk categories that helps structure testing and reporting. A penetration test is the work of finding real, exploitable instances of those risks in a specific application. A report organised by the Top 10 tells you the categories were considered; it does not by itself tell you how thoroughly each was tested.
Does covering the OWASP Top 10 mean my application is secure?
It means the most common categories of failure have been examined. It does not cover everything: business logic specific to your product, tenant isolation in multi-tenant systems, and abuse of legitimate functionality all sit outside the list, and in our experience these produce some of the most serious findings.
Which OWASP Top 10 version do you test against?
The 2021 revision for web applications, alongside the OWASP API Security Top 10 for API work and the Mobile Application Security Verification Standard for mobile. Where your auditor requires an older revision for continuity, we map findings to it as well.
Do you test against the OWASP API Security Top 10 as well?
Yes, and for API work it is the more relevant list. The web Top 10 was written for applications rendered to a browser, so it under-represents failures specific to APIs such as object-level authorisation, excessive data exposure and unrestricted resource consumption. Where an engagement covers both a web front end and its APIs, we test against both lists and report against whichever your auditor expects.
How does the OWASP ASVS relate to the Top 10?
The Top 10 is an awareness document listing the most common risk categories. The Application Security Verification Standard is a detailed requirements checklist with three assurance levels, and it is far more suitable as a testing baseline. We use the Top 10 to structure reporting because auditors recognise it, and the ASVS to structure coverage because it is specific enough to test against.
Should every engagement cover all ten categories?
Coverage should be considered across all ten, but effort should not be distributed evenly. Access control, insecure design and authentication routinely produce the serious findings and consume most of the time. Spreading effort equally across categories to make a report look balanced is a common way to produce a document that covers everything and finds nothing.
Is the OWASP Top 10 relevant for internal applications?
Yes, and often more so. Internal tools are frequently built with the assumption that everyone using them is trusted, which means access control and input handling receive less attention than in customer-facing products. When those tools later become reachable from a wider network or acquire external users, the assumptions built into them become the vulnerability.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.