The OWASP Top 10, Through the Lens of an Automated ScannerSecurity2026-07-038 min read<br>The OWASP Top 10, Through the Lens of an Automated Scanner<br>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?<br>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.<br>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.<br>What can an automated scanner actually observe?<br>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.<br>That gives a scanner three kinds of evidence:<br>Passive observation. Headers, TLS parameters, cookies, version banners, and page content. Deterministic and low-noise.<br>Active probing. Crafted inputs sent to the application, with the response, timing, or error semantics read back in-band.<br>Data correlation. Fingerprinted products and versions matched against authoritative CVE data, with EPSS scores and CISA KEV context attached.<br>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.<br>How detectable is each OWASP category?<br>OWASP 2021 categoryExternally visible signalsScanner detectabilityA01: Broken Access ControlExposed admin paths, directory listing, unsafe HTTP methods, open redirectsPartialA02: Cryptographic FailuresTLS versions and ciphers, certificate problems, missing HSTS, mixed contentStrongA03: InjectionError signatures, reflected payloads, timing differencesStrongA04: Insecure DesignMissing rate limiting, account enumeration, weak CSRF defensesLimitedA05: Security MisconfigurationMissing security headers, version disclosure, debug endpoints, permissive CORSStrongA06: Vulnerable and Outdated ComponentsFingerprinted versions matched to CVE dataStrongA07: Identification and Authentication FailuresLogin over HTTP, weak session and token handlingPartialA08: Software and Data Integrity FailuresMissing Subresource Integrity, exposed CI configurationPartialA09: Security Logging and Monitoring FailuresVerbose errors, missing security.txt, leaky robots.txtLimitedA10: Server-Side Request ForgeryURL-fetching parameters confirmed with in-band probesPartialThe table is the summary; the sections below explain the reasoning behind the ratings.<br>Which categories does automated scanning catch well?<br>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.<br>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.<br>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...