Passive and active website scanning: what is the difference

Two kinds of checks

The terms come from security testing. NIST SP 800-115, a standard guide to security testing, describes passive discovery as observing traffic without sending a single probing packet, and active discovery as sending packets to make systems respond. Active techniques find more in less time, but they create extra network load, can trigger intrusion detection and reveal where they come from.

A website check cannot be passive in that strict sense, because it has to request your pages. So we describe ours by what it does. The public ZNIMOK check makes the same kind of requests a browser or a search engine makes (GET and, where useful, HEAD), at a low rate, and reads public records about the domain. Anything beyond that waits until the owner has proved control of the site.

What a passive check can see

• DNS records: SPF, DMARC, DKIM on common selectors, MX, CAA, DNSSEC and CNAMEs that point to services that no longer exist.
• The TLS certificate and the HTTPS setup: validity, expiry date, the redirect from HTTP, HSTS.
• Response headers of the homepage: security headers, cookie flags, version numbers in Server or X-Powered-By.
• Technologies and versions the site reveals, matched against end-of-life data and public vulnerability databases.
• Whether well-known files and paths answer a normal request, such as security.txt, xmlrpc.php or a forgotten debug.log.
• Public records about the domain: registration data, hostnames in Certificate Transparency logs, and open ports already listed in public internet scan data such as Shodan InternetDB, without connecting to those ports ourselves.

What a passive check cannot see

• Anything behind a login: admin settings, user accounts, plugin configuration.
• Whether a vulnerability can really be exploited. A version that matches a known CVE means “may be affected, needs checking”, not “vulnerable”.
• Flaws in your own code, such as SQL injection or cross-site scripting, which need active testing of forms and parameters.
• Ports and services that do not appear in public data, and versions that the server hides.
• Malware and blacklist status: ZNIMOK does not check for those.

A clean passive report means “nothing found in what we could see from outside”, not “the site is secure”.

What active checks add

Active checks send traffic the site would not get from an ordinary visitor. The main ones at ZNIMOK:

• A port scan: connection attempts to a curated list of ports on your hosts, to see which services answer directly from the internet.
• A deep audit, which can also send POST requests to the owner’s own API endpoints and forms.
• Smaller probes such as open redirect, Host header and WebSocket tests.

They are useful for an owner who wants a fuller picture, and unwelcome when someone points them at a site they do not run. That is why they need ownership proof.

Why active checks need ownership proof

Anyone can type any address into a public form. If that form started port scans and POST requests on any site, strangers could test sites they have no right to test, and the targets would carry the load and the security alerts.

So active checks run only on a site with a stored ownership verification. On such a site they can be part of any check, also one that someone else starts, and their results are shown only to the verified owner. For a site without verified ownership the check stays read-only and relies on public data instead.

How ownership is verified

In the ZNIMOK dashboard (it requires an account) each site gets its own verification code. Add the code in one of three ways and click “Verify ownership”:

The TXT record is looked up on the registrable domain. The file and the meta tag are fetched over HTTPS from the site’s host, the main domain and its www host. The code proves control only; it gives ZNIMOK no login and no access to your server.

If you see our requests and want them to stop

The scanner information page describes what the check requests and how it behaves: low concurrency, pacing, and backing off when a site answers with HTTP 429 or a firewall challenge. If your site slows the check down or blocks it, the report marks the coverage as partial instead of claiming a clean result.

If you do not want ZNIMOK to check your site at all, email security@znimok.com from an address at that domain, with the site address and, if you have it, the IP address you saw in your logs. We handle each request by hand and reply. The same address is published in our /.well-known/security.txt, the contact file format defined in RFC 9116.