Passive vs Active Security Scanning: What a Scanner Should Refuse to Do to Your Site
The line between observing a site and attacking one is sharper than vendors make it sound. What passive scanning can honestly find, what genuinely needs active testing, and the tests we refuse to run — with reasons.
Webcuris Research
Security Engineering
·2 min read
Passive scanning observes what a server already says to anyone: response headers, TLS parameters, DNS records, certificate transparency logs, the behaviour of an ordinary page load. Active scanning sends traffic designed to make something misbehave: injection payloads, authentication guesses, malformed requests. The distinction sounds academic until you notice what it decides — whether a scan can safely run continuously against production, and whether it can harm people who never consented to being tested.
What passive observation honestly finds
More than the word "passive" suggests. Without sending a single hostile byte, a scanner can read:
- Every security header and its exact value — a CSP that is present and useless, cookie flags, HSTS max-age.
- The complete TLS posture — protocol versions, certificate chain, expiry.
- The domain's email authentication — SPF, DKIM, DMARC records and what they actually authorize.
- Your subdomain estate — certificate transparency logs are public, and they remember every certificate you ever issued.
- Framework and server disclosures — the versions your responses volunteer.
- Dependency risk — advisories matched against what your pages load and what your repository declares.
That list covers the large majority of what actually goes wrong on real websites — misconfiguration, drift, and known-vulnerable components, not exotic zero-days.
What genuinely needs active testing
Confirming that an injection is exploitable — not just that inputs are reflected — requires sending payloads. So does testing authentication logic, business-logic flaws, and access control between accounts. That work is real and valuable. It is a pentest: scoped, time-boxed, authorized in writing, run by a person who can stop when something looks fragile — not a robot re-running attacks against production on a schedule.
The tests we refuse to run, with reasons
Some active tests are refused here even when the customer asks, because the harm falls on people who did not consent:
| Refused test | Who it hurts |
|---|---|
| Credential stuffing / brute force | Real users, locked out of their accounts — the test is the attack, indistinguishable in the target's own logs |
| Conclusive SQL / command injection | A payload that proves execution executes — on somebody's production database or shell |
| Request smuggling & cache poisoning probes | Other people's users, served a poisoned response from a shared cache |
| Active prototype-pollution probing | Every other user of the process, until it restarts |
| Rate-limit enforcement testing | The service itself — proving a limit exists means bursting past it |
A vendor with a longer feature list than this either runs those tests — worth asking how they contain the harm — or checks a proxy and names it after the attack. Both are worth knowing before you point anything at production.
Why continuous monitoring must be passive
Monitoring's value is running every day against production — that is what catches the regression the day a deploy causes it. A test too dangerous to run unattended daily therefore cannot be part of monitoring, whatever its one-off value. The honest architecture is both, separately: passive checks continuously, and a human-driven pentest at the cadence your risk justifies. A Webcuris scan is the first half, and says so — every check it runs is one your site already answers for anyone who asks politely.
Keep reading
What Is Continuous Website Security Monitoring? (And When a One-Time Scan Is Enough)
Two very different things are sold under one name. What posture monitoring actually watches, what a regression looks like, which checks belong on a schedule — and the honest cases where a single scan is all you need.
Security Monitoring for SaaS Startups: What Enterprise Buyers Check Before They Ever Talk to You
Before the first call, somebody on the buyer's side points a scanner at your domain. What they see, the questionnaire answers passive monitoring writes for you, and the posture ladder to climb before paying for an audit.
Security Monitoring for Web Agencies: Every Client Site, One Answer
An agency's security surface is every site it ever shipped, including the ones nobody bills for any more. The risks specific to running many sites with a small team, the per-client baseline worth standardizing, and the honest case for monitoring as a service line.