Website Security Scanner
Generate an in-depth security report for any public website: TLS protocol support, certificate health, HTTP security headers, DNS and DNSSEC, SPF/DKIM/DMARC, cookies and mixed content — with a prioritised remediation plan you can print or download.
This lookup runs on our servers because it queries public infrastructure. Only the hostname you submit is sent; results are cached.
Enter a domain to generate a full security report.
What is Website Security Scanner?
A passive website security scan inspects the security configuration a site publishes — its TLS certificate and protocol, HTTP response headers, DNS records and email authentication policies — without sending any traffic designed to probe, fuzz or exploit the target.
What this Website Security Scanner does
Enter a domain and the scanner performs three independent checks in parallel: it completes a TLS handshake on port 443 and reads the certificate, it fetches the homepage and analyses the response headers, and it queries public DNS for the records that govern certificate issuance, resolution and email authentication.
Each check produces findings graded as pass, warning, issue or informational. Those roll up into per-category scores and one overall score out of 100.
The output is a full report, not just a score: an executive summary, a remediation plan ordered by impact, every finding with its fix, and a technical appendix containing the TLS protocol matrix, certificate detail, DNS and email records, response headers and the redirect chain. You can print it to PDF or download it as Markdown or JSON.
Everything it does is something any visitor’s browser already does. No ports are scanned, no inputs are fuzzed, no vulnerabilities are exercised.
How to use it
- Enter a domain such as
example.com. A full URL works too. - Read the overall score, then the per-category breakdown.
- Work through the issues first, then warnings. Each finding explains what it means and how to fix it.
- Re-run after making changes. Results are cached for five minutes.
Understanding your results
The overall score is the mean of the category scores. Each finding deducts points — 20 for an issue, 8 for a warning — and informational observations deduct nothing.
HTTPS covers whether the site is served over TLS and whether HSTS is published with a meaningful lifetime.
TLS covers the certificate itself: chain validity, hostname coverage, days until expiry, and the protocol version negotiated.
Headers covers CSP, clickjacking protection, MIME-sniffing, referrer policy and permissions policy.
DNS covers CAA records restricting certificate issuance, and nameserver redundancy.
Email covers SPF and DMARC — including the RFC 7208 ten-lookup limit, which silently disables SPF when exceeded.
Cookies covers the Secure, HttpOnly and SameSite attributes on any cookie set by the homepage response.
Why this matters
Most of what this scanner checks is invisible until it fails. A certificate expires on a Saturday. An SPF record quietly crosses ten lookups when marketing adds another provider, and from that moment every receiver treats SPF as broken. A CSP is deployed and never revisited while unsafe-inline stays in it.
None of these produce an error anyone sees until something breaks in public. Checking the published configuration from the outside is the cheapest way to catch them.
Common mistakes
Reading a high score as “secure”. It means the published configuration is sound. It says nothing about application code, dependency versions, access control or whether the site is already compromised.
Assuming HTTPS alone is enough. Without HSTS, a browser’s first plaintext request can be intercepted before the redirect happens.
Leaving DMARC at p=none indefinitely. Monitoring mode is the correct first step and provides no protection on its own. The point is to reach quarantine or reject.
Adding a CSP with unsafe-inline and considering it done. That combination permits exactly the injected inline script CSP exists to stop.
Technical background
The TLS check opens a socket to port 443 with SNI set to the hostname and reads the presented certificate chain. Certificate validation is evaluated rather than enforced, so an invalid chain can be reported instead of simply refusing to connect.
The HTTP check follows redirects one hop at a time, re-validating the destination at every hop. The DNS check resolves A, AAAA, MX, NS, TXT, CAA and SOA records, plus TXT at_dmarc, and parses SPF and DMARC according to RFC 7208 and RFC 7489.
Limitations
This is a configuration audit, not a penetration test. It cannot find SQL injection, cross-site scripting, broken access control, vulnerable dependencies, exposed admin panels or leaked credentials.
Only the homepage response is analysed. Headers and cookies can differ on other routes, and often do on authenticated pages.
DNSSEC validation status is not determined — the resolver used does not expose the AD bit, and reporting a status we have not verified would be worse than reporting none.
Sites behind a CDN or WAF may return configuration belonging to the edge rather than the origin.
Only public hostnames on ports 80 and 443 are accepted. Private, loopback and cloud-metadata addresses are refused by design.
Frequently asked questions
Is this scan intrusive? Will it show up as an attack?
No. It makes one HTTPS request to the homepage, one TLS handshake and a handful of DNS queries — the same traffic any visitor generates. It sends nothing designed to probe or exploit, and it identifies itself in the User-Agent.
Do I need permission to scan a site?
For these passive checks, no more than you need permission to visit the site in a browser. Anything more invasive — port scanning, vulnerability probing — does require authorisation, which is why this tool does not do it.
Does a score of 100 mean my site is secure?
No, and it is important to be clear about this. It means the configuration this scan can observe is sound. Application vulnerabilities, outdated software and compromised systems are all invisible to a passive external check.
Why did my site score badly on email when it does not send mail?
A domain that sends no mail still needs SPF and DMARC, otherwise anyone can spoof it. For a non-sending domain publish "v=spf1 -all" and a DMARC record with p=reject.
Can I scan an internal or localhost address?
No. Private, loopback, link-local and cloud-metadata addresses are refused, and hostnames are re-checked after every redirect. Allowing them would turn this tool into a proxy into our own network.
How often can I run a scan?
Twelve scans per minute per IP address, with identical targets cached for five minutes. That is generous for a person and restrictive for a script.
References
Last reviewed