HTTP Security Header Checker
Paste raw response headers and get the security-relevant ones graded against current practice. Parsed in your browser — nothing is fetched or transmitted.
Paste HTTP headers to analyze
Copy headers from your browser DevTools → Network tab
The security headers, in order of what they actually buy you
| Header | Protects against | A sane starting value |
|---|---|---|
| Content-Security-Policy | Cross-site scripting, data exfiltration, clickjacking | default-src 'self'; object-src 'none'; base-uri 'self' |
| Strict-Transport-Security | Protocol downgrade and cookie hijacking after the first visit | max-age=31536000; includeSubDomains |
| X-Content-Type-Options | MIME sniffing turning an upload into executable script | nosniff |
| Referrer-Policy | URLs — often containing tokens or IDs — leaking to third parties | strict-origin-when-cross-origin |
| Permissions-Policy | Embedded content silently using camera, mic or geolocation | camera=(), microphone=(), geolocation=() |
| X-Frame-Options | Clickjacking. Largely superseded by CSP frame-ancestors | DENY |
| Cross-Origin-Opener-Policy | Cross-window attacks; required for high-resolution timers | same-origin |
X-XSS-Protection is obsolete and should be removed rather than set. The browser XSS auditors it controlled were themselves exploitable and have been withdrawn from every major engine.
Capturing the headers to paste
This tool analyses headers you supply rather than fetching a URL itself. That is a deliberate trade: it works on hosts a fetch could never reach.
- curl —
curl -sI https://example.comprints response headers only. Add-Lto follow redirects and see the final response, or drop-Ifor the full exchange. - Browser devtools —Network tab → click the document request → Headers → Response Headers. Use "Raw" to get them in the paste-ready form.
- Staging and internal hosts —This is where a paste-based checker wins. Anything behind a VPN, a private network or basic auth can be captured locally and analysed here — an online scanner cannot reach it at all.
- Authenticated responses —Headers on a logged-in page frequently differ from the public one — particularly Cache-Control and Set-Cookie, which is exactly where the mistakes are. Capture the real authenticated response.
- Behind a CDN —Compare headers from the CDN edge against your origin. Proxies routinely add, strip or rewrite headers, and the difference is invisible until you look at both.
CSP is the one worth the effort
Content-Security-Policy is the only header on that list that meaningfully changes what an attacker can do after finding an injection point, and it is also the only one that takes real work to deploy.
The difficulty is that a strict policy breaks inline scripts and styles — which most real sites have, often from third-party tags nobody remembers adding. The path of least resistance is 'unsafe-inline', which switches off essentially all of CSP's XSS protection while leaving the header present. A policy containing 'unsafe-inline' in script-src should be read as "no CSP".
The workable approach is nonce-based: generate a random nonce per request, put it in the header and on every legitimate <script> tag. Injected script has no nonce and does not execute. Add 'strict-dynamic' so scripts your trusted code loads are permitted without enumerating every CDN.
Deploy with Content-Security-Policy-Report-Only first. It reports violations without blocking anything, so you find out what breaks before your users do. Leave it in report-only for a week of real traffic, fix what it surfaces, then enforce.
Header problems worth checking for
Headers look fine here but the browser still warns
Cause:You captured the headers from a different response than the browser saw — a redirect hop, a cached response, or the origin rather than the CDN edge.
Fix:Follow redirects (curl -IL) and confirm you are reading the final 200 response for the exact URL the browser loaded.
HSTS present but ineffective
Cause:A max-age of a few hundred seconds, or the header served over plain HTTP. Browsers ignore HSTS delivered over HTTP, by design.
Fix:Serve it only over HTTPS with max-age of at least 31536000 (one year). Add includeSubDomains and preload only when you are certain every subdomain, forever, will support HTTPS — preload is very hard to undo.
Access-Control-Allow-Origin: * alongside credentials
Cause:A wildcard origin combined with Access-Control-Allow-Credentials: true. Browsers reject this combination, so the request fails — but seeing a wildcard at all on an authenticated API suggests CORS was loosened to make an error go away.
Fix:Echo back a specific origin validated against an allow-list. Never reflect the Origin header unconditionally: that is equivalent to allowing every site.
Server and X-Powered-By disclose exact versions
Cause:Default configuration. Not a vulnerability in itself, but it hands an attacker a version to look up in a CVE database.
Fix:Suppress or genericise them. Marginal benefit, near-zero cost.
Cache-Control missing on an authenticated response
Cause:Without it, intermediate caches and the browser may store a page containing another user’s data. Shared computers and corporate proxies make this a real exposure.
Fix:Send <code>Cache-Control: no-store</code> on anything user-specific. For public assets, the opposite applies — long max-age with a content hash in the filename.
Set-Cookie without Secure, HttpOnly and SameSite
Cause:Defaults. HttpOnly keeps a cookie out of reach of injected JavaScript; SameSite mitigates CSRF; Secure prevents transmission over HTTP.
Fix:Set all three on session cookies: <code>Secure; HttpOnly; SameSite=Lax</code>. Use SameSite=None (which requires Secure) only when a cookie genuinely must travel cross-site.
About
The HTTP Header Analyzer parses raw HTTP response headers you paste in, categorizes every header by type (security, CORS, caching, authentication, content, other), and evaluates the security posture of your server configuration. Each header entry is expandable to show what the header does and whether its current value represents a good practice, a warning, or a potential misconfiguration. The Security Score (0–100) summarizes the overall posture: it deducts points for missing best-practice security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, COEP) and for headers with problematic values. A "Missing security headers" panel shows exactly which important headers are absent. All analysis runs entirely in your browser — the headers you paste are never sent to any server.
How to use
- 1 Copy HTTP response headers from your browser DevTools (Network tab → select a request → Response Headers) or from curl output.
- 2 Paste the headers into the left panel — the analysis updates immediately.
- 3 Click "Load example" to see a sample analysis of a well-configured server.
- 4 Review the Security Score and the missing headers list to identify gaps.
- 5 Click on any individual header row to expand it and read the description, expected values, and any risk note.
- 6 Use the category labels (Security, CORS, Caching, Auth, Content) to focus on a specific area.
- How do I get the response headers for my website?
- Open your browser DevTools (F12 or Cmd+Option+I), go to the Network tab, navigate to your website, select the main HTML request, and copy the "Response Headers" section. You can also use curl: run `curl -I https://yourdomain.com` in a terminal to get only the response headers.
- What is the Security Score based on?
- The score starts at 100 and deducts points for missing best-practice security headers (10 points each) and for headers with poor values — for example, an HSTS max-age under one year (-5), a CSP with unsafe-inline/unsafe-eval (-5), or a server header leaking version details (-5). A score of 80+ is good; 60–79 needs improvement; below 60 has significant gaps.
- What does "unsafe-inline" in a Content-Security-Policy mean?
- unsafe-inline allows inline JavaScript and inline CSS to execute without restriction, which defeats XSS protection for those content types. Modern CSP best practice avoids unsafe-inline by using nonces or hashes for legitimate inline content instead.
- Why is HSTS max-age important?
- HSTS (HTTP Strict Transport Security) tells browsers to only connect via HTTPS for the duration specified by max-age (in seconds). A max-age of at least 31,536,000 (one year) is required for HSTS preload lists, which prevent first-visit downgrade attacks. Shorter values mean the browser could be downgraded to HTTP after the period expires.
- Is my data sent to any server?
- No. The entire analysis runs in JavaScript in your browser. The headers you paste are never transmitted anywhere — this makes it safe to paste headers from internal APIs, staging environments, or any server you would not expose publicly.
More in Network & Security
See all network & security.