HTTP Headers Analyzer
Paste a response’s headers and see what they protect and what they leave open: HSTS, CSP, framing, cookies, caching, CORS and what the server gives away — graded and explained.
HTTP Headers Analyzer
Response headers
Grade a response’s headers
Paste the headers of any response to see its transport, framing, sniffing, referrer, cookie, caching and CORS settings — and the lines that fix what is missing.
Raw headers from curl -I, curl -v or the Network tab · a redirect chain is fine; the last response is graded
How is this calculated?
HSTS follows RFC 6797 (a repeated directive invalidates the header; only the first header counts). Cookies follow RFC 6265bis and what browsers ship: SameSite=None needs Secure, __Host- needs Secure, Path=/ and no Domain, Max-Age wins over Expires, lifetimes are capped at 400 days. Referrer-Policy uses the last value a browser understands. The grade counts only the security headers — an error twice, a warning once — from A (nothing found) to F (five or more). It describes what the headers ask of a browser, not how secure the site is.Runs in your browser — nothing you enter leaves this device.
About this tool
What it does
Reads the headers of an HTTP response and says, header by header, what they ask a browser to do and what they leave open. Security headers: Strict-Transport-Security, Content-Security-Policy (summarised; the CSP Evaluator goes directive by directive), framing (CSP frame-ancestors or X-Frame-Options), X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the cross-origin isolation headers. Every Set-Cookie: Secure, HttpOnly, SameSite, the __Host- and __Secure- prefixes, Domain, Path and lifetime, including the combinations browsers reject outright. Caching, where a shared cache could hand one visitor’s cookie to another. CORS response headers, and the Server and X-Powered-By lines that tell an attacker what to try.
How to use it
- Get the headers: curl -I https://your-site (or curl -sv … for the redirects too), or the browser’s Network tab → the request → Response Headers → Raw.
- Paste them. A redirect chain is fine: each response is read, and the last one — the one the browser acts on — is checked.
- Work through the findings marked Fix first, then Check. Each says which rule it applies and what to send instead.
Limits and your data
- It reads headers, not pages: a CSP in a <meta> tag, or a cookie set by JavaScript, is not seen here.
- It cannot tell whether a header suits your site — a long HSTS lifetime on a domain that still needs plain HTTP somewhere will break it.
- HSTS only takes effect over HTTPS; the tool cannot know which scheme the response came over.
- The headers are read in your browser and never sent anywhere; the page works offline. Cookie values you paste stay on this device — but they are credentials, so remove them before sharing a screenshot.
Questions
Why does a missing HttpOnly count as a warning for one cookie and only a note for another?
A cookie whose name looks like a session or token (session, sid, auth, token, jwt…) is what an injected script would want, so HttpOnly matters most there. Other cookies — a theme, a language — may be read by your own JavaScript on purpose.
Is X-XSS-Protection still useful?
No. Browsers removed the XSS auditor it controlled, and in old browsers it could be abused. Send 0 or nothing, and rely on a Content-Security-Policy.
Do I need both X-Frame-Options and frame-ancestors?
Browsers that support CSP use frame-ancestors and ignore X-Frame-Options. Sending both protects very old browsers as well; frame-ancestors alone is enough for current ones.
Why is Cache-Control: public a problem with Set-Cookie?
public (or s-maxage) lets a CDN store the response, Set-Cookie and all, and serve it to the next visitor — who then gets the first visitor’s cookie. Responses that set cookies should be private or no-store.