Inputs
Example
Paste headers from curl or fetch https://example.com to inspect CSP, HSTS, X-Content-Type-Options, cookies, and cache policy.
HTTP Header Analyzer
Analyze pasted HTTP response headers locally, or fetch headers for a public URL through the restricted endpoint.
Good for checking CSP, HSTS, cookies, cache behavior, framing policy, and content-type signals without a full scan.
Headers are your security policy in transit
Almost everything a browser is told about how to treat a site travels in response headers: whether transport security is mandatory, what content may execute, whether the page may be framed, how cookies are scoped, how long caches may hold a response. That makes headers the fastest honest audit surface there is — and also a place where policies rot quietly, because a header removed during a debugging session or duplicated by a second proxy layer rarely announces itself.
This analyzer reads a response-header set and organizes it into practical groups: security headers, caching, content typing, cookies, isolation and framing policy. It flags what is missing, what is contradictory, and what is duplicated — the duplicate case matters more than people expect, because when a CDN and an origin both set the same header, what the browser enforces may be neither of the two values you intended.
From raw response to prioritized findings
Paste headers when you already have them — from curl, browser developer tools, or a proxy — since that keeps the analysis fully local and works for responses the public internet cannot reach. Use the live fetch for the outside view of a public URL: it also records the redirect chain and the final URL, which is often where the interesting surprises live, because each hop in a redirect chain carries its own header set.
Work the findings by leverage. Transport and execution policy first: HSTS and Content-Security-Policy decide entire attack classes. Then cookie attributes and framing, then cache correctness — miscached personalized content is a security incident wearing a performance costume. Treat warnings as prompts rather than verdicts, and after every fix, re-run against the deployed site: header changes have a habit of passing review and then being absorbed by a middlebox on the way to production.
Fetch guards and analysis boundaries
Pasted headers stay in the browser. Live fetches go through /api/http-headers.php, which accepts full http or https URLs on ports 80 and 443 only, rejects embedded credentials, blocks private, loopback, link-local, multicast, and reserved resolved addresses, follows a small redirect chain, and sends no request body. The analyzer evaluates response headers — it does not parse page content, execute scripts, or replace a full vulnerability scan, and header policy is always judged against what the specific application needs.
Frequently asked questions
Why not fetch every URL directly from the browser?
Because CORS deliberately prevents a page from reading response headers of arbitrary other sites. The same-origin endpoint performs one guarded fetch on your request and returns the headers for local analysis.
Does a warning mean the site is insecure?
Not automatically. Header policy is application-dependent — an API responds differently than an HTML page, and an intranet tool differently than a shop. A warning marks a decision worth checking, not a proven defect.
Why do duplicate headers get their own findings?
Because they are usually a symptom of layered infrastructure — CDN, load balancer, origin — each adding its own policy. Browsers resolve duplicates in ways that vary by header, so the effective policy can silently differ from every individual layer's intent.
What should I look at first on a typical site?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, and cookie attributes. Those four decide the biggest attack classes; most of the remaining findings are refinement on top.
Can the live fetch scan internal URLs?
No. The endpoint requires public DNS names and rejects private and reserved resolved addresses. For internal systems, capture the headers there and use the paste path — the analysis itself is identical.
Why does the redirect chain matter for a header audit?
Because each hop is a separate response with its own headers, and protections missing on an early hop are missing for real users. An HSTS header only on the final HTTPS response, but not on the redirecting hosts, is the classic gap this view exposes.