What a website vulnerability scan does and doesn't cover

"We ran a security scan and it came back clean" is one of the most misunderstood sentences in web work. It can mean a great deal or almost nothing, depending on what the scan was able to see. This guide draws the boundary of external, unauthenticated website scanning as precisely as it can, so you can set expectations before a scan rather than defend them afterwards.

The vantage point

An external website scanner stands where an anonymous visitor stands: on the public internet, with no account, looking at whatever the site sends in response to ordinary requests. Everything it can and cannot do follows from that position. It sees what a browser would see. It does not see the server's filesystem, the database, the source code, the admin area or the internal network. Keep that picture in mind and most of the questions answer themselves.

What it does cover

Transport security

Whether the site forces HTTPS, which TLS versions and ciphers the server accepts, and whether the certificate is valid, complete and not about to expire. This is fully observable from outside and scanners are reliable at it. See TLS and certificate analysis.

Browser-facing defences

The response headers that tell browsers how to protect users: HSTS, Content-Security-Policy, framing rules, cookie attributes and so on. Also fully observable. See HTTP security headers.

Information the site gives away

Version strings, verbose error pages, directory listings, developer comments, exposed configuration or backup files, readable .git directories, forgotten test pages, admin panels reachable from the internet. Scanners find these by requesting known paths and reading responses, and they find them often. These are among the most consequential findings an external scan produces, because they are what an attacker's reconnaissance finds first.

Known-vulnerable components

A CMS, plugin, framework or JavaScript library whose version has published advisories. Detectable when the version is visible; actionable with the caveat that version is not proof of exploitability. See curated Nuclei checks.

Common misconfigurations

Permissive CORS, open redirects detectable without payloads, mixed content, missing cache controls on sensitive-looking pages, third-party scripts loaded without integrity checks. Passive analysis of normal traffic catches these. See passive OWASP ZAP.

Indicators of injection flaws

Passive scanning can notice the preconditions for cross-site scripting and similar bugs, such as input reflected in a page. Active scanning, which sends test payloads, can confirm many of them. Whether a given scan includes active testing is the single most important thing to know about its coverage; the first release of ScanBastion does not. Passive vs active scanning explains the difference.

What it does not cover

Anything behind a log-in

Account areas, dashboards, checkout steps after the first, and anything else that requires a session are not visited by an unauthenticated scan. For many applications that is where most of the code, and most of the risk, lives. Authenticated scanning exists but requires credentials, careful scoping and an application that tolerates it; it is a separate engagement.

Business logic

Can a user change the price in the cart? Can one customer see another's invoice by changing a number in the URL? Can a discount code be applied twice? These are the flaws that cause real losses, and no scanner finds them, because recognising them requires understanding what the application is supposed to do. Only a person testing with intent does.

Novel flaws in custom code

Scanners match patterns: known paths, known version strings, known response signatures. A SQL injection in a bespoke search feature, an authorisation bug in a custom API, a file-upload handler that trusts the extension, none of these are patterns. Finding them is penetration testing or code review.

The infrastructure around the website

Mail servers, databases, SSH, VPN endpoints, cloud storage buckets, DNS configuration and the rest of the attack surface are outside a website scan. Some website scanners include a port scan; many, including ScanBastion's first release, deliberately do not.

The organisation

Phishing resistance, password reuse, who has admin access, whether backups are tested, whether the developer's laptop is encrypted. The majority of real-world compromises start here, and no website scan has anything to say about it.

What "clean" means

A scan report with no findings means: the checks that ran, from outside, against the public parts of the site, at the time of the scan, did not detect anything they are designed to detect. Each clause matters. A good report states which checks ran, which were skipped or timed out, and what was out of scope, on the first page, next to the summary. If a report does not say what it did not do, be suspicious of what it claims to have done.

Setting expectations with a client

A sentence that works: "An automated scan checks the public side of the site against a large list of known problems, quickly and repeatably. It will catch outdated software, exposed files and missing protections. It will not test the parts of the site that need a log-in, and it cannot find flaws in how the site's own features work. For those, we recommend a manual test, and here is when that is worth it."

Said before the scan, that sentence makes the scan a useful tool. Said after a breach, it is an excuse. The habit of writing the boundary into every report, every time, is what separates a security deliverable from a reassurance.