HTTP Header Checker Online

The response headers actually worth auditing

Most headers are noise; a short list carries real security weight:

• Strict-Transport-Security (HSTS) — forces HTTPS for a set duration so a downgrade or a typed http:// can't be intercepted. Powerful, and a commitment (see below).
• Content-Security-Policy (CSP) — the strongest defence against cross-site scripting, whitelisting where scripts, styles, and other resources may load from. Also the modern way to control framing, via frame-ancestors.
• X-Content-Type-Options: nosniff — stops browsers from second-guessing a response's declared MIME type, blocking a class of attacks where an upload is coaxed into running as script.
• Referrer-Policy — controls how much of your URL leaks in the Referer header on outbound clicks; strict-origin-when-cross-origin is a sane default.
• X-Frame-Options — the old anti-clickjacking header. It still works, but it is superseded by CSP frame-ancestors, which is more flexible; set the CSP directive and X-Frame-Options becomes redundant.

One header to stop using: X-XSS-Protection. The legacy browser XSS auditor it toggled has been removed from modern browsers and could itself introduce vulnerabilities; current guidance is to omit it and rely on CSP instead.

HSTS and preload: easy to switch on, hard to switch off

Strict-Transport-Security tells browsers “only ever reach me over HTTPS for the next max-age seconds.” That is what you want — until you consider how you turn it off. Because the directive lives in each browser's memory, not on your server, shortening or removing it only takes effect the next time a visitor happens to hit your site and receive the new header. Ship a long max-age and then need to serve something over plain HTTP, and you are stuck waiting out the clock in every visitor's browser.

The preload flag raises the stakes. Adding your domain to the HSTS preload list bakes the HTTPS-only rule directly into browser binaries, covering even a visitor's very first request. Removal from the preload list is slow and ships on browser release cycles — potentially months. Preloading also typically commits every subdomain to HTTPS. Treat max-age plus preload as a promise you must keep for the whole duration, including for subdomains you may not have migrated yet.

Why 'unsafe-inline' quietly defeats your CSP

A Content-Security-Policy earns its keep by refusing to run script the page didn't explicitly authorise. The whole model rests on the browser being able to tell your scripts from an attacker's injected ones. The moment your policy contains script-src 'unsafe-inline', that distinction collapses: you have told the browser to run any inline <script> on the page, which is exactly what an XSS payload is. Such a policy still looks like a CSP in a header audit but provides almost none of CSP's core protection.

Teams reach for it because eliminating inline scripts is real work, so the intended path is a nonce or hash: attach a per-response random nonce to the scripts you trust, so the browser runs those and rejects everything else. If you only audit for the presence of a CSP header you will miss this — you have to read what the policy actually allows.

Cache-Control and ETag do different jobs

Two caching headers get conflated. Cache-Control sets the policy — how long a response may be reused without asking again (max-age), whether shared caches may store it (public/private), and whether it must be revalidated (no-cache, which despite its name means “revalidate before use,” not “don't store”). ETag is a validator: an opaque fingerprint of the response body. When a cached copy goes stale, the client sends the ETag back in If-None-Match, and the server can reply 304 Not Modified with no body, saving the download while confirming freshness.

The classic mistake is relying on one and expecting the other's behaviour — an ETag with no Cache-Control still forces a round-trip on every request (just a cheap one), while a long max-age with no validator means you cannot cheaply confirm a stale asset hasn't changed. For static assets the durable pattern is a long max-age plus a content hash in the filename, so the URL itself changes when the bytes do.

Why a browser can't always read every header

This tool tries a direct request from your browser first, which returns the full raw header list — but only for endpoints that opt in with permissive CORS headers (many APIs, CDNs, and static hosts do). For a site that doesn't, the browser's security model deliberately hides most response headers from JavaScript; otherwise you could read authenticated headers from any site the user is logged into. When that happens the tool falls back to a server-side proxy, which still reports real response metadata — status code, content type, size, and the final URL after redirects — but not the complete header set.

So a partial result here doesn't mean the site is misconfigured; it means the site doesn't expose its headers to cross-origin browser scripts. For the definitive, unfiltered header list, request the URL from outside a browser — curl -I https://example.com — where no CORS policy applies.