Passive scanning inspects the responses a server already gives to ordinary requests and reasons about them, while active scanning sends crafted, sometimes hostile requests to provoke a flaw into revealing itself. The difference is whether the scanner tries to change a system's behaviour or only observes it, and that single distinction drives everything about safety, authorisation and what each approach can prove.
Almost every debate about scanner accuracy, legality and risk comes back to this boundary. Get it clear and you can choose the right tool for a job, explain to a client why one scan needs a signed authorisation and another does not, and read a report knowing which findings are confirmed and which are inferred.
Where the line actually is
The test is not "did the scanner send network traffic" (every scanner does) but "did it send input designed to alter behaviour or trigger a fault." A passive scan fetches a page, reads the headers, parses the HTML, notes the TLS parameters of the connection it made anyway, and looks up DNS. Everything it learns, the server volunteered to a normal visitor. An active scan goes further: it injects a single quote into a parameter to see if the database errors, submits a script fragment to see if it reflects unescaped, or requests thousands of guessed paths to map hidden content.
There is a grey zone worth naming, because tool vendors blur it. Directory brute-forcing, requesting thousands of common paths to find hidden pages, sends only ordinary GET requests, yet it is unmistakably active: the intent is to discover what the server did not volunteer, and the traffic pattern is nothing like a real visitor. The same is true of user enumeration, which sends valid-looking login requests to learn which accounts exist. Neither sends a classic "payload," but both cross the line from observing to probing, and both belong on the active side of the fence. When you judge a tool, watch its intent and its traffic shape, not just whether the word "exploit" appears in its documentation.
Side by side
| Passive scanning | Active scanning | |
|---|---|---|
| Requests sent | Normal, browser-like | Crafted payloads, fuzzing, path guessing |
| Risk to target | Negligible | Real: errors, data changes, downtime |
| Authorisation | Best practice, low stakes | Mandatory and specific |
| Confirms injection/XSS? | No, only infers | Yes, can demonstrate |
| Confirms config/disclosure? | Yes | Yes |
| Noise in logs | Looks like a visitor | Obvious, often alerts defenders |
What a passive scan finds well
A surprising amount of a site's security posture is visible without sending a single payload, because servers advertise it. From ordinary responses alone, a passive scan can judge:
- Transport security — the TLS versions and ciphers the server negotiated, the certificate chain and its expiry, and whether deprecated TLS is still offered.
- HTTP security headers — whether HSTS, Content-Security-Policy and clickjacking protection are present and sensibly configured.
- Cookie flags — the
Secure,HttpOnlyandSameSiteattributes on cookies the server sets. - Client-side code — the JavaScript libraries a page loads and their versions, matched against known-vulnerable releases.
- Information disclosure — server and framework version banners, generator tags and comments the server hands to anyone.
These are exactly the layers Scan.now grades. None of them requires an attack; they require careful reading. That is why our website vulnerability scanner can return a full letter grade while remaining entirely non-intrusive.
What only active scanning can prove
Some classes of flaw are, by nature, unprovable without interaction. A passive scanner might notice a form parameter that echoes into the page and suspect reflected cross-site scripting, but confirming it means submitting a payload and observing execution. The same is true of SQL injection: you cannot demonstrate that input reaches a query without sending input crafted to bend that query. Broken access control, server-side request forgery and most of the interactive half of the OWASP Top 10 live here.
How the well-known tools split
The open-source ecosystem maps neatly onto this divide. ZAP (formerly OWASP ZAP) runs a passive scan on all proxied traffic and an active scan you switch on deliberately. Nuclei runs templated requests that range from benign fingerprinting to genuine exploitation, depending on the template. testssl.sh probes TLS actively but harmlessly against the protocol itself. Retire.js is purely passive: it reads which libraries loaded. Knowing which mode a tool is in tells you how much you can trust a finding and how much noise you are making. We compare them in open-source security scanners.
Choosing the right mode
- Start passive, always. It is safe, fast and finds the majority of real-world exposure, most of which is misconfiguration rather than exotic injection.
- Escalate to active only with authorisation and, ideally, against staging rather than production first.
- Rate-limit and schedule active scans so they do not overwhelm the target or drown defenders in alerts.
- Treat active findings as confirmed, passive findings as leads — and reproduce anything before you act on it, as our guide to what a vulnerability scan is stresses.
The false-positive trade-off
The two modes also differ in how much you can trust a raw finding. An active tool that demonstrated an effect, an error it provoked, a script it saw execute, produces high-confidence results: it watched the thing happen. A passive tool infers, and inference can be wrong. The classic passive false positive is a server that advertises an old version in its banner but was actually patched without updating the string; the scanner reports a vulnerability that no longer exists. The classic passive false negative is a protection the scanner cannot see, a web application firewall that would block the payload the passive scanner never sends.
This does not make passive findings unreliable; it makes them leads that need confirmation, which is true of any finding but especially so here. The discipline is the same one every scan demands: reproduce the evidence before you spend engineering time on it. A missing header is trivially confirmed by fetching the response yourself. A suspected injection is not confirmed until someone, with authorisation, sends the payload and watches the result. Keeping that distinction sharp is what separates a useful report from a noisy one, and it is the reason we describe passive findings as observations and active findings as demonstrations.
Being a good network citizen
Even passive scanning is not free of etiquette. A scanner that crawls aggressively can still generate load, trip rate limits, or clutter a site's analytics with traffic that looks like a bot, because it is one. The considerate defaults are modest concurrency, respect for robots.txt where it signals intent, and a recognisable user agent so an operator who notices the traffic can understand what it is. Active scanning multiplies every one of these concerns: fuzzing an endpoint can fill a database with junk, trigger transactional emails to real people, exhaust a rate-limited third-party API you depend on, or, against a fragile service, cause an outage that looks exactly like the denial-of-service attack you were not authorised to perform. This is why the authorisation for an active test is usually specific about timing, scope and rate, not a blanket yes. Treat the target's stability as your responsibility for the duration of the test, schedule heavy scans for quiet hours, and keep a way to stop instantly if something behaves unexpectedly. The professionalism of a scan is measured partly by how little collateral disturbance it causes.
Scan.now stays on the passive side by design. It is the fastest way to know whether the observable, common weaknesses are handled, and it does so without touching anything an attacker's payload would touch. For the deeper, interactive testing, bring in an active tool and a human, with permission in hand.
