Learn
Passive vs active scanning: what each one sends to your website
"Passive" and "active" are the two words that decide how much risk a vulnerability scan poses to the site it is pointed at. They are used loosely, which is a problem when you are asking a client for permission. This guide defines them in terms of the one thing that actually matters: the requests the site receives.
The distinction in one sentence
A passive scan sends only the requests a normal visitor would send and analyses the responses. An active scan sends requests crafted to provoke a vulnerable behaviour, and watches for it.
Everything else, from the risk to the coverage to the kind of authorisation you need, follows from that.
What a passive scan sends
A crawler fetches the home page, follows links within the site up to some depth and page limit, and fetches the scripts, styles and images those pages reference. That is it. On the server, the access log looks like a visitor who clicked through a lot of pages quickly. The analysis happens on the scanner's side afterwards: looking for missing headers, insecure cookie flags, version strings, developer comments, mixed content, reflected parameters and so on.
Two further kinds of check are usually grouped with passive scanning because they are equally benign. TLS analysis opens a number of TLS handshakes offering different protocol versions and ciphers; each is a legitimate connection attempt. Known-path probing, such as requesting /.env or /.git/HEAD to see if they are exposed, sends ordinary GET requests for specific URLs. It is sometimes called active because the paths are chosen deliberately, but the requests themselves are harmless; the worst outcome is a 404 in the log.
Risk to the site: load, and only load. A passive scan with a sensible rate limit is indistinguishable from a busy user. A passive scan without one can behave like a small denial-of-service against a fragile server, which is why rate limits, page caps and timeouts matter more than the passive label itself.
What an active scan sends
An active scanner takes every input it can find, such as URL parameters, form fields, headers and cookies, and submits variations designed to trigger specific bugs: SQL fragments to detect injection, script tags to detect cross-site scripting, path sequences to detect traversal, oversized or malformed values to detect handling errors. It submits forms, often many times. For each input it may send dozens or hundreds of requests.
On the server, the log looks like an attack, because technically it is one, performed with permission. The volume is one or two orders of magnitude higher than a passive crawl. More importantly, the requests have side effects on any application that is not purely read-only:
- Contact forms send real emails, hundreds of them, to the client's inbox.
- Comment and registration forms create junk records in the database.
- Search features with slow back-ends can be driven to exhaustion.
- Anything that triggers an outbound action, such as a webhook, an SMS or an order, triggers it repeatedly.
- Rate limiters and fraud systems may lock legitimate users out, or lock the scanner's IP out and make the results meaningless.
None of this is hypothetical; every penetration tester has a story about the staging site that turned out to be production. Active scanning is run against production only with a named person's explicit agreement, usually against a scoped set of paths, with forms that have side effects excluded, and ideally against a staging copy instead.
What each can find
| Finding type | Passive | Active |
|---|---|---|
| TLS and certificate issues | Yes | Yes |
| Missing or weak security headers | Yes | Yes |
| Insecure cookie attributes | Yes | Yes |
| Exposed files, directories and panels | Yes, by known-path requests | Yes |
| Outdated software versions | Yes, where the version is visible | Yes |
| Information leakage in pages | Yes | Yes |
| Reflected input (XSS precondition) | Noticed, unconfirmed | Often confirmed |
| SQL injection, command injection | No | Often, for simple cases |
| Path traversal, file inclusion | No | Often |
| Business-logic and authorisation flaws | No | No; manual testing only |
The pattern: passive scanning finds configuration, exposure and hygiene problems with high confidence, and finds the preconditions for injection bugs without confirming them. Active scanning confirms many injection bugs, at the cost of traffic and side effects, and still misses anything that needs understanding of the application's purpose.
Which to use when
- First look at any site, especially a client's production site: passive. It is safe, fast and finds the issues that attackers find first.
- Recurring monitoring of many sites: passive. The findings are stable, comparable over time and cheap to re-run.
- Before a launch, after a major change, or when the stakes justify it: active against staging, or a manual penetration test, with the owner's written scope.
- Never: active scanning of a production site because the tool offered a button for it.
Where ScanBastion sits
The first release of ScanBastion is passive by design: headers, TLS, passive OWASP ZAP analysis and a curated set of non-intrusive Nuclei templates that request specific known paths and read the responses. It does not send attack payloads or submit forms. That is a deliberate choice for a tool meant to be pointed at client production sites by people who are not full-time security testers. The Responsible Scanning Policy spells out the limits, and the scan engine pages describe exactly what each check sends.