Security Headers Checker
Type an address. You get the six headers that matter, each with what its value actually achieves — and the ones that are there doing nothing get said so.
Why “present” is not a score
Every other checker grades by presence: the header is there, green. But a header can be there and do nothing at all — max-age=0 is the documented way to turn HSTS off, a policy in Report-Only mode reports and blocks nothing, and frame-ancestors makes the browser ignore your X-Frame-Options entirely. All three read as done. That is worse than missing one, because a header you can see is a header you stop checking.
What this does not tell you
Whether your site is safe. These headers limit what an attack can do once something has gone wrong; they do nothing about the bug that let it in. A perfect six here sits happily on top of an unpatched CMS.
If you are here, this is usually what comes next
One photo, or the whole film
This is how the site looks right now. Monitoring watches it — the certificate, the DNS, the availability — and tells you the day something changes, which is usually the day somebody deployed a config they did not read.
Frequently asked questions
- It says my header does nothing. I can see it in the response.
- So can we — that is the point. Three of these are present and inert in the wild all the time: HSTS with max-age=0 (that is the instruction to forget it), a Content-Security-Policy sent only as Report-Only (it reports, it blocks nothing), and an X-Frame-Options on a site whose policy also carries frame-ancestors, which the browser obeys instead. The value is in the report; check it against what you meant to set.
- Do I need all six?
- Five of them are a line of server config each and there is no reason not to. The Content-Security-Policy is the one that takes real work, because a strict one breaks inline scripts until you fix them — and it is also the only one that limits the damage of an XSS rather than hoping to prevent it. Deploy that one in Report-Only first, read the reports, then switch it on.
- Why is unsafe-inline a problem if everything else is locked down?
- Because it is the thing a CSP exists to stop. With unsafe-inline in script-src, an injected script tag runs — which is the whole attack. Everything else the policy restricts is worth less than that one gap. Nonces or hashes are the way out, and strict-dynamic lets you keep unsafe-inline as a fallback for old browsers without it counting against you.