What Are HTTP Security Headers and Why Do They Matter?
HTTP security headers are response headers a server sends that tell the browser how to behave defensively when rendering that page: whether to enforce HTTPS, which sources are allowed to run scripts, whether the page can be framed by another site, and how much of its own URL it should leak to other sites it links to. None of them are visible in a page's HTML; they only show up in the raw HTTP response, which is exactly what this security headers checker connects to and reads. Getting them right is one of the highest-leverage, lowest-effort things a site can do for its own security posture: most are a single line in a server config or middleware, with no functional trade-off for real users.
What Does a Security Headers Checker Test?
This checker runs four groups of live tests against the URL you enter. Core security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy) are the baseline every site should have. Cross-origin isolation headers (COOP, COEP, and CORP) are more advanced, opt-in hardening most sites can skip unless they need specific browser APIs. Cookie security checks the Secure, HttpOnly, and SameSite flags on every cookie the response actually sets. And information-disclosure checks flag headers like Server and X-Powered-By that hand an attacker your tech stack for free. Every result shows the real header value behind the verdict, not just a pass/fail label, and a How to Fix panel with real Apache, Nginx, Cloudflare, and PHP snippets on anything that needs attention.
HSTS, CSP, and X-Frame-Options, Explained
Strict-Transport-Security (HSTS) tells the browser to only ever connect over HTTPS for a given duration (max-age), closing the window an attacker on the same network could use to silently downgrade a visitor to plain HTTP. Content-Security-Policy (CSP) is the strongest defense against cross-site scripting: it tells the browser exactly which sources scripts, styles, and other resources are allowed to load from, so even if an attacker manages to inject a `<script>` tag, the browser refuses to run it. X-Frame-Options (and its modern replacement, CSP's frame-ancestors directive) controls whether your page can be embedded in an `<iframe>` on someone else's site: without it, an attacker can overlay invisible UI on top of your page and trick users into clicking things they didn't mean to (clickjacking).
Cross-Origin Isolation and Cookie Security
Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy are a newer, more advanced set of headers that isolate your page's browsing context from other origins at the process level: they're what unlocks powerful browser APIs like SharedArrayBuffer, and they close side-channel attack classes like Spectre. Most sites don't need all three, which is why this checker treats their absence as an opportunity, not a failure. Cookie security is checked separately: the Secure flag stops a cookie from ever being sent over plain HTTP, HttpOnly stops it from being read by JavaScript (limiting the damage an XSS bug can do), and SameSite controls whether it's sent on cross-site requests at all, which is a first line of defense against CSRF.
Security Headers vs SSL/TLS: What's the Difference?
These test two different layers, and a site can score well on one while scoring poorly on the other. SSL/TLS security (certificate validity, chain of trust, negotiated protocol version and cipher) is about whether the connection itself is properly encrypted and authenticated; check that with this site's SSL/TLS Checker. Security headers are a separate, opt-in layer of browser-enforced rules that sit on top of a secure connection: CSP, HSTS, frame protection, and the rest. A site with an excellent TLS setup can still ship with no CSP and no HSTS header, and in fact several very well-known sites do exactly that. Neither check substitutes for the other; a thorough audit runs both.