Why I Built a Security Scanner That Never Touches the Target

A client asked me to build a "quick security check" tool for their agency's lead generation funnel, the kind where a visitor types in a domain and gets a security score back. Simple enough in concept. Then I actually sat down to build it and ran straight into a legal wall I hadn't fully thought through.

Here's the problem. The obvious way to build something like this is to run an active scan: port scan the target, maybe throw a few known exploit checks at it, see what comes back. That's how most security scanning tools work, and it's also, depending on jurisdiction, potentially illegal if you don't own the system you're scanning. Where I operate, unauthorized access to a computer system, even a read-only probe, falls under the same statute as actually breaking in. A visitor typing a random competitor's domain into my tool and getting me to port-scan it on their behalf was not a liability I wanted to hold.

So the tool had to be entirely passive. No packet gets sent to the target system, full stop. Everything comes from third-party services that have already scanned the internet and cached the results, meaning I'm querying a database, not the target.

Four sources ended up covering most of what a basic security posture check needs.

SSL Labs' API gives you certificate validity, protocol version, and cipher suite strength without touching the target directly beyond what a normal HTTPS handshake would do anyway, since that's inherent to loading the page at all.

Shodan and Censys are the interesting ones. Both continuously scan the entire public IPv4 space and cache what they find, open ports, running services, banner strings. Querying their API means you're reading data they already collected, not initiating your own scan. This is the core trick that makes passive scanning legally defensible: the scanning already happened, by someone else, and it's public information now.

Certificate Transparency logs, queried through crt.sh, turned out to be the most useful source for a specific failure mode I kept seeing in the wild: forgotten subdomains. Every SSL certificate ever issued for a domain gets logged publicly, permanently, as part of the CT system browsers now require. That means every staging., test., or old-checkout. subdomain someone spun up two years ago and forgot about is sitting in a public log somewhere, discoverable, and usually running whatever unpatched software was current when it was abandoned.

CIRCL's CVE API rounds it out, cross-referencing any software versions I can passively fingerprint against known vulnerabilities.

The interesting engineering constraint here wasn't really the APIs themselves, it was designing the whole pipeline around the assumption that I have zero interaction with the target beyond what a normal browser request already does. Every design decision funnels back to that one rule. It's a narrower tool than an active scanner would produce, the report is genuinely less deep than what a real pentest gives you, but it's a tool anyone can point at any domain without a lawyer getting involved, and for a lead-gen funnel that's actually the more useful trade-off.

If you're building something similar and want to compare notes on the passive-only approach, or want to see it running, I write about the infrastructure and security side of my work at resuloztas.com