Scanner Methodology

How a scan runs

A scan takes one URL and runs in waves, each wave in parallel with its own timeout. A full scan finishes in 30 to 60 seconds. The target is validated first: addresses in private, loopback and cloud-metadata ranges are refused, DNS is resolved once and the probes connect to that validated address, and every redirect hop is re-validated before it is fetched. A check that fails or times out returns an empty result and never aborts the scan.

The scanner produces 31 result families, listed below, plus four derived values: the CVE list, the OWASP mapping, the grade and its colour. The TypeScript result type documents 28 of the 31; ai_readiness, protocol_extras and a thirty-first internal key (site_owner, used only to choose the language of follow-up e-mail and not a security check) were added later.

There is deliberately no single "number of checks" on this page. A check has no fixed unit: one family can be one handshake or seventy-one path probes. The counts you see below are the lengths of the lists in the code.

What the scanner sends, and what it does not

Most of it is what a browser or search bot would send: a GET for the homepage, GETs for 71 well-known paths, a TLS handshake, DNS queries. Response bodies are read only for the homepage and error pages (capped at 2 MB); path probes read the status line and headers and stop.

Some probes go beyond reading. These are all of them:

• TCP connects to 10 ports, with no data sent.
• One anonymous FTP login attempt on port 21.
• SMTP connections on ports 587, 465 and 25 to read TLS support. No mail is sent.
• Requests carrying an Origin header, to see whether it is echoed back.
• TRACE, DELETE and PUT requests to the URL, with no body and with redirects off.
• Up to two requests with SQL-injection-shaped query strings (a WAF probe, sent only when no WAF is recognised from headers, and one to /index.php), to read how the site responds.
• Five sequential GETs to look for rate limiting.

Nothing is exploited. No payload is sent that tries to read, change or delete data, no credentials are submitted or guessed, and no brute force is attempted. The PUT and DELETE requests carry no body, but a server that treats a bodiless PUT or DELETE on its root URL as a real operation would act on it. That is a rare configuration, and it is the reason to scan only sites you own or have permission to scan.

Some lookups go to third parties, who then see the scanned URL or domain: VirusTotal (when configured), PhishTank, AlienVault OTX, URLhaus, Spamhaus, urlscan.io (unlisted, when configured), crt.sh and Shodan InternetDB, plus NVD, OSV and the retire.js database on GitHub for version matching.

The 31 result families

For each family: how it is probed, and what it contributes to the grade. "Not graded" means the result appears in the report but changes neither the OWASP mapping nor the letter.

OWASP Top 10 mapping

Findings are filed under OWASP Top 10 (2021) categories by rules in the analyser, not by a language model. Each category with at least one finding gets one risk level from the rule in the right-hand column. A04 Insecure Design and A10 Server-Side Request Forgery are never produced.

How the A to F grade is calculated

The grade is computed from the risk level of each OWASP category, not from individual findings. The analyser counts how many categories are Critical, High and Medium (Low is ignored). The code tests the rules from F down to A and the first match wins, so a result that satisfies both E and F is an F:

In the current rules only A03 and A06 can ever be Critical, so at most two categories reach Critical. That means 3 Critical categories is out of reach and F requires the second branch: A03 and A06 both Critical plus at least two High categories.

The grade is a rough ranking of how many separate areas have problems. It is not a risk assessment, and it is not comparable with the grade of another tool.

Limitations and false positives

Each of these follows from how the code works today. They are the reasons to read a finding as a lead to verify, not as a verdict.

• A 200 on a probed path is a hit, whatever the page contains. A site that answers 200 to every URL (many single-page apps do) can look like it exposes /admin/, /.env or /api/. The scanner does not read the body to confirm.
• The error-page check matches short keywords such as rails, django or line. A page that merely contains those words can be flagged.
• The HTTP method check flags any answer other than 403, 404, 405 or 501. A catch-all that returns 200 to PUT or DELETE is flagged even if the request changed nothing.
• Version-based CVE matching only works when the version is visible. A server that hides its version produces no CVE matches, which is absence of evidence and not a clean bill.
• The no-rate-limiting finding fires whenever no login page and no X-RateLimit header is found. That is true of most sites, so A07 is typically Medium and an A grade needs every other category to be Low or absent.
• If the header request itself fails, the header result is empty and HSTS is reported as missing.
• Redirect findings of any kind, even a 302 from http to https, land in A02 and make that category Medium.
• Cookies, DNS email authentication (SPF, DMARC, DKIM, MTA-STS, TLS-RPT), FTP, SMTP and blocklist results are reported but do not change the grade. A site with a weak DMARC policy can still score A.
• Only 8 of the 10 OWASP Top 10 (2021) categories are ever produced. A04 Insecure Design and A10 Server-Side Request Forgery are not mapped. The mapping is heuristic: exposed files are filed under A03 and a missing security.txt under A09 because those are the closest buckets the scanner has, not because OWASP defines them that way.
• Grading counts categories, not findings. A category with twenty findings counts once, the same as a category with one.
• Third-party sources (VirusTotal, urlscan.io) are used only when an API key is configured; otherwise they are marked unavailable and add nothing. Any source can also time out, in which case its result is empty.