Security headers checker

HTTP security headers, and what each one actually prevents

Every HTTP security header explained: HSTS, CSP, cookie attributes, frame and content-type options. What each one does and the mistakes that make it useless.

Start a free check Read the headers guide

What this check reads

Every HTTP response your server sends to a browser carries a set of headers. Most of them are not for the browser's benefit: they are instructions to the browser about what it is allowed to do with what it just received, and they are the only place a server gets to give those instructions without shipping code.

They are also, uniquely, entirely visible from outside. A header check needs no credentials, no cooperation from the target and no access to your infrastructure — which makes it the cheapest layer of an external assessment to run and one of the most frequently misconfigured.

The headers that carry security weight

HTTP security headers, what each one prevents, and the common misconfiguration
Header	What it prevents	The common mistake
Strict-Transport-Security	A visitor's first request being downgraded to plain HTTP, which is where a network attacker strips TLS instead of merely observing it.	Sent without `max-age`, or with a max-age of a few seconds, which achieves nothing.
Content-Security-Policy	Injected script running in your origin. It is the only broadly-effective control against cross-site scripting, because it constrains where a script may come from rather than trying to recognise a bad one.	A policy wide enough to include `'unsafe-inline'` alongside a nonce, which permits exactly what the nonce was there to prevent.
X-Content-Type-Options	A browser treating a non-HTML response as HTML because the server did not say not to.	Being sent as `nosniff` but not actually enforced upstream, or being omitted on error responses.
Set-Cookie attributes	A stolen session cookie being replayed. `Secure` keeps it off plain HTTP, `HttpOnly` keeps it out of reach of injected script, `SameSite` keeps it off cross-site requests.	Setting a session cookie without `HttpOnly` — which converts any XSS into a full account takeover.
X-Frame-Options / frame-ancestors	Your pages being embedded in a frame on somebody else's site, which is the delivery mechanism for clickjacking.	Trusting a single header when the CSP `frame-ancestors` directive exists, so the protection depends on which header a browser happens to prefer.
Referrer-Policy	Internal paths and identifiers leaking to third parties through the `Referer` header on outbound links.	Defaulting to `strict-origin-when-cross-origin` and never narrowing it to `no-referrer` on paths that carry identifiers.
Permissions-Policy	Features you never use — camera, microphone, geolocation — being available to any code running on your pages.	Being absent, which leaves every feature at its browser default rather than at yours.
Cross-Origin-Opener-Policy	A cross-origin page reaching back into your tab through `window.opener`.	Confusing it with `Cross-Origin-Embedder-Policy`, which breaks cross-origin resources if set without care.
Permissions on cacheable responses	A response containing one user's data being served from a shared cache to another.	`Cache-Control: no-store` missing from a page that renders per-user content.

Each row corresponds to checks the assessment runs and reports individually — HDR-001 to HDR-037 for presence and quality, CSPX-001 to CSPX-010 for policy quality, and CKI-001 to CKI-021 for cookie attributes. A report names the ones that applied to your site.

How to read a header finding

A missing header is a straightforward finding. A present but ineffective one is the more common and much more interesting case, and it is the reason a report grades policy quality separately from presence:

CSP present, CSP doing nothing. A policy that allows inline script, or a wildcard, or both. The header is in the response and the browser enforces it, and enforcing it changes nothing.
A nonce that never varies. Nonces are only safe if they are unpredictable and single-use. One reused across several script tags is a value an injected script can read and reuse.
A policy with no fallback. object-src and base-uri are worth setting explicitly; without them a permissive default-src becomes the answer to questions you never asked.
HSTS with a short max-age. A policy that expires while a visitor has the site open stops protecting them, silently.

These are the checks behind the headers guide, which walks through each one with the configuration that fixes it.

What a header check cannot tell you

Headers are a control, not a measurement

A missing header is evidence of a missing control, not of a vulnerability that exists today.
Headers do not make a site secure on their own. A perfect header set with one injection flaw in the application is still one injection flaw away.
Only headers returned to an unauthenticated request are visible. Anything behind a login is not read.
A header check reads what the response says, not what the server does. A header and its enforcement are two different facts, and only the first is observable from outside.

Check your own headers

The header layer is part of every assessment, alongside DNS, email configuration, TLS and exposed surface.

Start a free check Read the headers guide

Free plan: one domain, four assessments a month, no card.