Security Headers Checker

Scan a live URL for the HTTP security headers that protect visitors. Enter an address and this tool fetches it and checks for the headers that matter — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the cross-origin isolation headers — and shows which are present, which are missing, and the value each one is set to.

How to use the Security Headers Checker

Enter a URL and press Check security headers. The tool fetches the page and reports:

• A score — how many of the recommended security headers are present out of the set checked.
• Each header with a pass / warn / fail marker, a one-line explanation of what it does, and the exact value the server sent.
• A note where a header is present but weak, for example X-Content-Type-Options set to something other than nosniff.

This is a live fetch, so it reflects production exactly. If you already have the raw headers in hand, the Security Headers Analyzer grades a pasted block instead.

What HTTP security headers do

Security headers are response headers that instruct the browser to enforce defensive rules on a page. They cost nothing to add, are invisible to users, and close off whole classes of attack — which is why a missing one is among the first things a security review flags. The headers this tool checks are:

• Strict-Transport-Security (HSTS) — forces every future request to use HTTPS, defeating protocol-downgrade and cookie-theft attacks on public networks.
• Content-Security-Policy (CSP) — whitelists exactly which scripts, styles and resources may load. The single strongest defence against cross-site scripting (XSS).
• X-Frame-Options — stops other sites embedding yours in an iframe, preventing clickjacking.
• X-Content-Type-Options: nosniff — stops the browser second-guessing the declared content type, which prevents a class of MIME-confusion attacks.
• Referrer-Policy — limits how much of your URL is leaked to third parties in the Referer header.
• Permissions-Policy — switches off powerful browser features (camera, microphone, geolocation) unless explicitly needed.
• Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy — isolate your page from other origins, mitigating Spectre-style cross-origin leaks.

No single header makes a site secure, and headers do not replace fixing the underlying code. But together they form a cheap, high-leverage baseline: HSTS and a solid CSP in particular prevent attacks that are otherwise hard to defend against. The aim is to have every recommended header present with a sensible value.

Common use cases

• Pre-launch security review — confirm the baseline headers are in place before a site goes live.
• Verifying a hardening change — check that a new CSP or HSTS policy actually shipped to production.
• Vendor and third-party checks — quickly assess the header hygiene of a service you depend on.
• Compliance evidence — capture which security headers a site sends for an audit or checklist.
• Learning by example — inspect how well-secured sites configure their CSP and related headers.

Headers are a baseline, not a fix

Security headers are necessary but not sufficient. Keep their role in perspective:

• CSP reduces XSS impact, it does not remove the bug. A strong policy blocks injected scripts from running, but you still fix the injection. Treat CSP as defence in depth.
• HSTS needs HTTPS everywhere first. Adding includeSubDomains before every subdomain serves HTTPS will break the ones that do not. Roll it out carefully — see the HSTS Checker.
• A header present is not a header correct. A permissive CSP with unsafe-inline passes a presence check but offers little protection. Read the value, not just the existence.
• Order of priority. If you can only add a few, start with HSTS, X-Content-Type-Options: nosniff and X-Frame-Options, then work up to a real CSP.