Security

HTTP Headers

View response headers and audit security policies.

URL http or https (default https). Up to 3 redirects are followed.

Try: github.com cloudflare.com example.com mozilla.org

About this tool

HTTP Headers fetches your URL with a real HTTPS request, captures every header in the response (and every intermediate response along any redirect chain), and runs the result through a security audit covering the modern hardening headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Each header is checked for presence, value sanity, and best-practice gaps.

Beyond the audit, we list every header verbatim so you can confirm caching policy (Cache-Control, ETag, Vary), CDN tracing (CF-Ray, X-Cache, X-Served-By), compression (Content-Encoding: br/gzip), and any custom headers your stack emits. The HTTP method (GET or HEAD), HTTP version negotiated (HTTP/1.1, HTTP/2, HTTP/3), and TLS version are reported in the request bar.

When to use this tool

Security hardening. Before going live, confirm HSTS, CSP, and the rest are set with safe values — Mozilla Observatory baseline at minimum.
Cache debugging. See exactly what Cache-Control and Vary your CMS or framework emits — common cause of "old version sticking around".
Redirect chain audits. Spot accidental 302-then-301 chains, HTTP-to-HTTPS-to-different-host loops, and missing canonicalisation.
CDN behaviour. Confirm Cloudflare/Fastly/CloudFront is actually caching what you think it is by reading the Age, X-Cache, and CDN-specific headers.

What our security audit covers

For each of the six hardening headers we report: present or missing, the actual value, and a short verdict ("good", "needs tightening", "vulnerable"). HSTS without includeSubDomains, CSP with unsafe-inline, or Referrer-Policy left at default get flagged. We never tell you the "perfect" policy because every site is different — but we tell you which knobs are still at the factory setting.

Frequently asked questions

What is HSTS and why does it matter?

Strict-Transport-Security tells the browser "always use HTTPS for this domain, even if the user typed http:// or clicked an http:// link". Once set with a reasonable max-age (typically 31536000 = 1 year), it prevents SSL-stripping attacks on subsequent visits. Adding includeSubDomains extends the protection to every subdomain — strong default for most sites but make sure all of them really do support HTTPS first.

My CSP is missing — how dangerous is that?

Without CSP, any XSS hole in your site executes with full power: it can exfiltrate cookies, load attacker-controlled scripts, or rewrite the DOM. A starting CSP of default-src 'self' blocks the most common XSS payloads (inline scripts, external script loads) at near-zero cost. Tighter policies that ban inline scripts entirely require refactoring but provide much stronger protection.

Do you follow redirects?

Yes — up to five hops. Each step is shown with its method, status, location, and headers so you can spot mixed-protocol hops (HTTP→HTTPS), missing canonicalisation (apex vs www), or accidental loops. Most production sites should redirect once at most (HTTP → HTTPS), then serve content; more than two hops is usually a sign of overlapping rewrite rules.

Why does the tool show HTTP/2 even when I configured HTTP/3?

HTTP/3 (QUIC over UDP) requires the client to opt-in via the Alt-Svc header on the first connection. Our checker uses HTTP/2 over TCP by default, which is what most HTTP clients still do today; if your server advertises HTTP/3 in Alt-Svc, you will see that header in the result, but the response itself is still over HTTP/2. The presence of Alt-Svc is the right thing to look for.