How the security headers check works
Every page your server sends comes with a few lines of instructions for the browser, called response headers. Some of them protect your visitors: they insist on a secure connection, limit which scripts may run, and stop other sites from framing your pages. This check reads them.
What it reads
- Your home page, and up to two pages linked from it, preferring pages such as login, account, contact or shop, where protection matters most. Following links is the one crawler-like step in a scan, so it respects your
robots.txt. - The Strict-Transport-Security header on other addresses under your domain that your own site names, in its certificate or on its pages (for example
www.orshop.), because that header is set per address.
No extra requests are made for this check beyond those pages: it reads the headers every visitor's browser already receives.
What it reports
- A missing Content-Security-Policy, or one so loose (
'unsafe-inline'scripts without nonces or hashes, or any source allowed) that it blocks very little. - A missing Strict-Transport-Security header, or one that expires in under a year.
- No clickjacking protection: neither X-Frame-Options nor
frame-ancestorsin the policy. - A missing X-Content-Type-Options: nosniff, Referrer-Policy or Permissions-Policy.
- Headers that announce software versions: a Server header with a version number, X-Powered-By, and the ASP.NET version headers.
A header missing on the home page is reported with every checked page that lacks it, so you can see whether it is a site-wide setting.
What it cannot see
- Headers on pages behind a login, or on pages the home page does not link to.
- Whether a policy fits your site. A Content-Security-Policy that passes this check can still be wrong for your pages; only testing in a browser shows that.
- A CDN or firewall in front of your site can add or remove headers. The check reports what reaches visitors, which is what counts, but the fix may belong in the CDN settings rather than on your server.
What to do with the result
Most header findings are a few lines of server or CDN configuration. The security headers guide explains each header in plain language and gives the values to ask for.
See what this looks like on your own site: a free, passive check in about two minutes.
Check my websiteEverything this check can report
- ModerateNo Content-Security-Policy header
- MinorContent-Security-Policy allows inline scripts or any source
- ModerateNo Strict-Transport-Security header
- MinorStrict-Transport-Security max-age below one year
- ModerateNo clickjacking protection (X-Frame-Options or frame-ancestors)
- MinorNo X-Content-Type-Options: nosniff
- MinorNo Referrer-Policy header
- InfoNo Permissions-Policy header
- MinorServer header discloses software version
- MinorX-Powered-By header discloses technology
- MinorASP.NET version headers present
- InfoResponse headers could not be checked
Severity is fixed per finding in our code and never set by the AI that writes the report text. How severity becomes a score is on the methodology page.
The other checks
- How the cookies check works · Whether the cookies your site sets are protected on the way and in the browser.
- How the secure connection check works · Your certificate, the encryption your server accepts, and whether visitors are moved to https.
- How the email and DNS check works · The public DNS records that stop fake email in your name, and addresses pointing to services you no longer use.
- How the technology check works · What your site is built with, worked out from what it shows publicly.
- How the vulnerability wave check works · Whether what we can see matches a major vulnerability in the news.
- How the known flaws in components check works · Whether a library or framework version your site shows has a published security advisory.