Passive and active scanning: what each finds and when you need it

Security tools that look at your domains from the outside fall into two families. A passive audit only reads what is already public. An active scan sends requests designed to make a weakness show itself. Both are useful; they answer different questions, carry different risks and need different permissions.

What a passive audit does

A passive audit behaves like a careful visitor. It queries DNS, reads certificate transparency logs, loads your home page, completes a TLS handshake, greets your mail servers and looks up public data sets that already index the internet, such as lists of open ports and known vulnerabilities.

It finds a lot: a missing DMARC policy, a certificate about to expire, a subdomain that can be taken over, a database port that answers the whole internet, an old version of a library announced in your page, a look-alike domain registered last week. Because it sends nothing unusual, it can run every day on every domain, without anyone signing anything.

Its limit is the word suspects. When a page announces WordPress 6.1 and a plugin with a known flaw, the audit can say the flaw is likely. It cannot say whether a security plugin, a firewall or a backported patch blocks it. It cannot see behind your login page at all.

What an active scan does

An active scan sends test requests: it asks for paths that should not exist, puts unexpected characters in forms and parameters, tries the requests that a known vulnerability needs, and watches how the application answers. Two kinds of tools do most of the work:

• Template scanners such as Nuclei send precise requests for known vulnerabilities, misconfigurations, exposed files and admin panels. Fast and precise, they find what is already documented.
• Web application scanners such as OWASP ZAP crawl the application, then try families of attacks on every parameter they find: SQL and command injection, cross-site scripting, path traversal. Slower, they find flaws in your own code too.

Given a test account, both can go behind the login, where most of the value of an application lives.

The risks of active testing

Active testing is not harmless, which is why it needs rules.

• Permission. Testing a system without its owner’s consent can be an offence in many countries. Only test what you own or what you have written permission to test, and keep that permission.
• Load. Thousands of requests in a few minutes can slow a small site down. Set a rate limit and a time window.
• Side effects. A crawler that clicks “delete”, “unsubscribe” or “pay” really does it. Sign-out pages end the session the scan relies on. Exclude them.
• Third parties. A subdomain can point at a server you do not run: a hosting provider, a SaaS platform, a former supplier. Check the addresses before testing them.
• Credentials. A test account must be a test account, created for this, never a production administrator, and its password must not travel in clear text or stay in a log.

Which one do you need?

Question	Passive audit	Active scan
Is my e-mail protected from spoofing?	Yes	No
Did a new subdomain or certificate appear?	Yes	No
Is a database or remote desktop open to the internet?	Yes, from public data	Not its job
Is this suspected vulnerability really exploitable?	Suspects it	Confirms or rules it out
Does my login form or search box have an injection flaw?	No	Yes
Can I run it every day on all my domains?	Yes	Rarely needed, and heavier

For most small companies and agencies the answer is both, in that order: a passive audit on every domain, all the time, and an active scan on the applications that matter most, a few times a month and after each significant release. Neither replaces a penetration test by a person, who finds logic flaws and chains of small weaknesses that no tool sees.

Combining them safely

1. Start passive. Fix what the audit finds: it is cheap, and it removes the noise an active scan would otherwise report.
2. Write the scope down. The hosts, the addresses they point to, the paths to avoid, the dates and hours, the maximum rate, the person who authorizes it.
3. Use a test account with realistic data and no real customers.
4. Warn your host and your security team, and tell them which address the requests come from.
5. Read the results against the audit. A suspicion confirmed by an active test goes to the top of the list; one that is not reproduced can wait, with the reason written down.

How Perimetry Cloud does it

Every Perimetry Cloud plan runs the passive audit. The verified active scan, coming soon as an option per domain, follows the steps above: it only runs on a domain you have proven, after an authorization signed in the application with the scope, the window and the rate, from one published address, with Nuclei and OWASP ZAP. Destructive tests, password guessing and sign-out, deletion and payment pages are left out, and each suspicion of the audit comes back confirmed or not reproduced.