The OWASP Top 10, Through the Lens of an Automated Scanner

TL;DR: Automated scanners are strong on the OWASP Top 10 categories that leave observable evidence: security misconfiguration, cryptographic failures, vulnerable components, and most injection classes. They are weaker where the flaw lives in business logic, such as broken access control and insecure design, which still require manual testing. Knowing which is which tells you exactly what a scan report covers and where a human tester needs to pick up.

Why view the OWASP Top 10 through a scanner's lens?

The OWASP Top 10 is the most widely used shorthand for web application risk, and most write-ups explain what each category means and why it made the list. If you want that grounding, Byte Optimizer publishes a general OWASP Top 10 explainer that walks through the categories and how the list has evolved.

This post takes a different angle. For each category, it asks one question: how well can an automated scanner detect it from the outside? The answer matters because it defines what a clean scan report actually proves. A scanner that reports "no findings" is not saying "no vulnerabilities." It is saying "no vulnerabilities of the kinds a scanner can see." Those are different statements, and confusing them is one of the most common mistakes in application security programs.

What can an automated scanner actually observe?

An external scanner works with the same raw material an attacker starts with: HTTP responses, headers, TLS handshakes, DNS records, and the way endpoints behave when probed. OnScanner, for example, runs live, never-cached scans against the real target, either unauthenticated (the anonymous attacker's view) or authenticated (the logged-in surface), and verifies selected findings with safe, non-destructive, in-band active checks. The full detection approach is documented on the methodology page.

That gives a scanner three kinds of evidence:

• Passive observation. Headers, TLS parameters, cookies, version banners, and page content. Deterministic and low-noise.
• Active probing. Crafted inputs sent to the application, with the response, timing, or error semantics read back in-band.
• Data correlation. Fingerprinted products and versions matched against authoritative CVE data, with EPSS scores and CISA KEV context attached.

What a scanner cannot observe is intent. It does not know which user should see which record, what a business workflow is supposed to allow, or what your internal logs capture. Each category's detectability follows directly from that boundary.

How detectable is each OWASP category?

The table is the summary; the sections below explain the reasoning behind the ratings.

Which categories does automated scanning catch well?

A02, cryptographic failures, and A05, security misconfiguration, are the scanner's home turf. Whether TLS 1.0 is still enabled, whether HSTS is present, whether a certificate has expired, whether a Content-Security-Policy exists, whether a server banner leaks a version: these are objective facts, observable in every response or handshake, with essentially no ambiguity. A scanner can check them on every run, at any frequency, without any risk to the target.

A06, vulnerable and outdated components, is almost purpose-built for automation. A scanner fingerprints products and versions, matches them against CVE databases, and attaches exploitation context such as EPSS scores and CISA KEV listings, which are covered in depth in EPSS and KEV explained. Automation also does something here that no human team can: re-checking the entire surface on a schedule as new CVEs are published against software you already run.

A03, injection, is more nuanced but still favorable. Error-based SQL injection, reflected cross-site scripting, and template injection produce discriminating markers that a scanner can safely elicit and read back. Blind and time-based variants are detectable through response timing. What automation tends to miss are second-order cases, where a stored payload only surfaces later in a different context, such as an internal admin panel the scanner never sees.

Where does automated scanning struggle, and why?

A01, broken access control, is the honest disappointment. It sits at the top of the OWASP list, and a scanner can only see part of it. The observable subset is real and worth catching: admin consoles reachable without login, directory listing, unsafe HTTP methods, exposed configuration files, open redirects. But the core of the category is authorization logic: can user A read user B's invoice by changing an ID in the URL? Answering that requires knowing what the application is supposed to allow, which is intent, not evidence. Authorization testing needs a human with two accounts and a hypothesis.

A04, insecure design, is by definition about controls that were never built. Automation can flag design smells that show up externally, like a login endpoint that accepts unlimited attempts or a password reset flow that confirms whether an account exists. It cannot evaluate whether a checkout flow can be abused, whether a trust boundary sits in the wrong place, or whether a threat model was ever written. Design review is a whiteboard activity, not a network activity.

A09, security logging and monitoring failures, is mostly invisible from outside. A scanner can check the disclosure hygiene that correlates with it: verbose stack traces, a missing security.txt file, a robots.txt that maps out sensitive paths. Whether you actually log authentication failures, and whether anyone reads those logs before an incident, cannot be observed from the network.

A07 and A10 sit in between. Authentication failures have detectable symptoms (login forms served over HTTP, weak token handling) while credential-lifecycle logic needs manual review. SSRF can be confirmed automatically when a URL-fetching parameter responds to an in-band probe, but chained SSRF paths deep inside application logic usually take a human to find.

How should you combine scanning with manual testing?

The table above suggests a division of labor rather than a competition.

Automated scanning provides breadth, frequency, and consistency. Every header, TLS setting, exposed path, and known CVE gets checked identically on every run, and scheduled monitoring catches drift the day it happens rather than at the next annual test. If you are setting up this layer for the first time, start with how to scan a website for vulnerabilities.

Manual testing provides depth on exactly the rows marked Partial and Limited: authorization matrices, workflow abuse, chained attacks that combine several low-severity findings into one real breach path. That work is a different discipline, and it is what a manual penetration test is for.

The mistake to avoid is treating either one as a substitute for the other. A yearly pentest with nothing in between leaves eleven months of unmonitored drift. Continuous scanning with no manual testing leaves the top category on the list only partially covered. The strongest programs run both and let each do what it is structurally good at.

Frequently asked questions

Can an automated scanner cover the entire OWASP Top 10?

It can produce findings in every category, but depth varies sharply. Misconfiguration, cryptographic failures, vulnerable components, and injection are covered well because they leave observable evidence in responses and handshakes. Broken access control, insecure design, and logging failures are only partially observable from outside, so a scanner covers their externally visible symptoms while the underlying logic flaws require manual testing.

Which OWASP categories most need a manual penetration test?

Broken access control and insecure design benefit most. Both depend on understanding what the application is supposed to allow, which cannot be inferred from responses alone. A tester with multiple accounts can systematically probe authorization boundaries, abuse business workflows, and chain low-severity findings into realistic attack paths. Logging and monitoring gaps also need internal review, since external scanning only sees their surface symptoms.

Does a clean scan report mean an application is secure?

No. A clean report means the scanner found no issues in the classes it can observe: configuration, transport security, known-vulnerable components, and injectable inputs. It says little about authorization logic, workflow abuse, or design gaps. Treat a clean scan as a strong baseline that rules out the most common attack paths, and schedule manual testing for the categories that remain.