What your server tells every browser.
We load your page once and read the security headers it sends — ranked by what an attacker would get, not alphabetically.
- One page, two requests
- No signup
- Results gone in 24 hours
What this checks
Security headers are instructions your server sends with every page, telling the browser what it may and may not do with it. Missing ones do not break anything you can see — they leave a door open.
https, and whether http forwards to it. A page on plain http hands everything on it to whoever is on the network, so it comes first.
Strict-Transport-Security, which keeps returning visitors on https.
Content-Security-Policy, which stops an injected script from running — and whether yours still allows `'unsafe-inline'`.
Framing protection against clickjacking.
X-Content-Type-Options, version numbers in `Server`, and cookies without `Secure` or `SameSite`.
What this is not
Not a vulnerability scan. We read what your server says about itself — the same headers any browser receives — and nothing more. Cookies are reported by name and flags only; we never store what is in them.
Security header questions
Why is Referrer-Policy not a finding?
Because browsers now default to a safe policy when it is missing. We show it in the table; we do not nag about a default that already protects you.
Will adding a Content-Security-Policy break my site?
It can, if it is strict from the start. Begin with `Content-Security-Policy-Report-Only` to see what it would block, then switch it on.
Where do I set these headers?
In your web server or CDN configuration — nginx, Apache, Caddy, Cloudflare or your host's dashboard — not in the page itself.