Security Header Checker

How to use it

1. 1Enter the address you want to checkType or paste it into the field marked "Address to check", including the https:// at the front. Use a page that matters — a login, a checkout, an admin screen.
2. 2Press Check and wait a few secondsThe request runs from our server rather than from your browser, so your cache, your extensions and your login session cannot affect the answer. That is the point of it: you are seeing what an anonymous visitor sees.
3. 3Look at which headers are missingEach header is reported with what it defends against, so the list is a set of decisions rather than a score to maximise. Not every site needs every header.
4. 4Start with the content security policyIt is the one that does the most and the one most often absent or so permissive it does nothing. A policy allowing unsafe-inline is reported, because that is the part most XSS relies on.
5. 5Check HSTS if you serve HTTPSWithout it, the first request a visitor makes can still go over plain HTTP. The tool reports its max-age and whether subdomains are included, since a short max-age offers little.
6. 6Treat this as a checklist, not a security auditHeaders are one layer. A page with a perfect set of them can still have an injection flaw behind it, and no non-invasive tool can tell you otherwise.
7. 7Share or keep the result within 24 hoursThe result has its own link you can send to whoever needs to act on it. It is deleted 24 hours after the check ran, so save anything you need to keep — and re-run the check after a change rather than trusting an old link.

About this tool

Browsers enforce a set of protections only when a site asks for them, by sending the right response headers. This tool reads those headers for one URL and judges each against current guidance, quoting the value it judged so you can check the reasoning rather than take it on trust.

Absence is treated as a finding rather than skipped. A page with no Content-Security-Policy is not unassessed — it is a page where any injected script runs, and the result says so along with what the missing header would have prevented.

Understanding the result

Fails come first, then warnings, then what is already right, because the useful order is the order you would fix them in.

Deprecated headers are judged in reverse: X-XSS-Protection, Expect-CT and Public-Key-Pins are flagged when present. All three went from recommended to harmful or useless, and guidance that still awards points for them is teaching an answer that expired years ago.

Cookies are assessed on their attributes — Secure, HttpOnly, SameSite — never on their values, which are frequently live sessions and are neither read nor stored.

Example

https://example.com/

1 protection missing
[Missing] Content-Security-Policy — any injected script runs
[Needs attention] Referrer-Policy: no-referrer-when-downgrade sends full URLs
[Good] Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options

Limitations

• Headers are read from one URL. Sites commonly send different headers for the home page, for authenticated pages and for API responses, so check the pages that matter rather than assuming the home page speaks for all of them.
• A Content-Security-Policy is assessed structurally: whether it exists and whether directives give back what it is for. Whether it actually covers everything your pages load needs the browser console, not a header check.
• Headers are one layer. They do not compensate for unescaped output, missing authorisation checks or vulnerable dependencies.
• Permissions-Policy and Cross-Origin-Opener-Policy are reported as optional rather than counted for or against — they are worthwhile but not universal expectations.

Questions