An external security scanner sees your application the way an anonymous visitor does: it makes requests, reads responses, and infers what it can. That vantage point is genuinely useful and strictly limited, and confusing "the scan is clean" with "the application is secure" is one of the more common ways teams end up surprised.
Worth being precise about where the line falls.
Passive and active scanning
Passive scanning observes ordinary responses without trying to break anything. It reads headers, inspects cookies, checks the TLS handshake, fingerprints JavaScript libraries and looks at the HTML. It cannot damage your application because it does nothing an ordinary browser does not do.
Active scanning sends deliberately malformed or unexpected input to see how the application reacts — injection payloads, path traversal attempts, forced browsing to guessed paths. It finds more, and it can create junk records, trigger workflows and occasionally take a fragile endpoint down. Passive vs active scanning is the main thing to settle before pointing any tool at production.
What an external scan reliably detects
| Category | Examples |
| Transport | Weak TLS versions, expired or mismatched certificates, missing HSTS |
| Headers | Missing or weak CSP, absent frame protection, permissive CORS |
| Cookies | Missing Secure, HttpOnly or SameSite flags |
| Disclosure | Version banners, generator tags, revealing HTML comments |
| Exposed paths | Version-control directories, environment files, backups, debug endpoints |
| Dependencies | Client-side libraries with published vulnerabilities |
| Content | Mixed content, missing subresource integrity, third-party scripts |
Two properties make these detectable: they are observable in a response, and correctness is decidable without understanding your business. A missing HttpOnly flag is missing regardless of what the application does.
What it cannot detect, structurally
Broken access control. The largest category of real-world web vulnerabilities and close to invisible externally. A scanner has no way to know that user A should not be able to read invoice 1043. It does not know who A is, what an invoice is, or which ones belong to whom. Detecting this requires two authenticated sessions and knowledge of the intended rules.
Business-logic flaws. Applying a discount twice, skipping a payment step, negative quantities, race conditions between two endpoints. Every request is individually well-formed and returns 200. There is nothing anomalous to observe.
Anything behind authentication. An unauthenticated scan reaches the login page and stops. On most applications that is a small fraction of the attack surface.
Server-side code paths. Vulnerable dependencies on the server, insecure deserialisation, weak cryptography at rest, secrets in source, insufficient logging — none of it observable from outside unless it happens to leak into a response.
Stored issues that need a trigger. A stored XSS payload that only renders in an admin panel is present, exploitable and unseen by an external scan.
Reading the output correctly
Two failure modes, both common. False positives: a header flagged as missing that is set by your CDN on the paths that matter, or a library version inferred from a filename rather than its contents. Always verify the specific finding against the specific request.
False confidence is the more dangerous one. "Zero findings" means the checks the tool performs did not fail, which is a much narrower claim than it feels like. It is worth knowing what a vulnerability scan actually covers before quoting a clean result to anyone.
Where scanning fits
- External scan. Continuous, cheap, catches configuration drift. Run it on a schedule.
- Authenticated scan. Covers the logged-in surface. More setup, considerably more coverage.
- Dependency and static analysis in CI. Catches server-side library issues and code patterns.
- Code review and threat modelling. The only thing that finds logic and authorisation flaws.
- Manual testing. A human who understands the domain, periodically.
Scanning is the bottom layer: fast, automatable, and covering the mistakes that are easy to make and easy to fix. It is a floor, not a ceiling, and treating it as either extreme is where teams get into trouble.