HTTP Header Analyzer
Paste response headers from curl or DevTools and get them explained, with missing security headers, CSP weaknesses, cookie flags and cache contradictions flagged.
Response headers
11 headersGet these from curl -I https://example.com, or DevTools → Network → Headers → Raw. This tool does not fetch the URL, which is what lets it work on an authenticated or internal response.
Verdict
HTTP/2 2003 errors, 10 warnings
Issues
13 shown- errorscript-src allows 'unsafe-inline', which defeats most of the protection CSP provides.
Use a nonce or a hash instead.
/content-security-policy/script-src
- errorscript-src allows any origin (*), which makes the directive decorative.
/content-security-policy/script-src
- errorCookie "session" has no Secure attribute, so it is sent over plain HTTP too.
/set-cookie/session
- warningAccess-Control-Allow-Origin is *, so any origin can read this response from script.
Correct for a public API. Wrong for anything behind authentication.
/access-control-allow-origin
- warningCache-Control has both no-cache and max-age; no-cache forces revalidation, so max-age has no effect here.
/cache-control
- warningNo frame-ancestors directive, so clickjacking protection depends on X-Frame-Options alone.
/content-security-policy/frame-ancestors
- warningBoth Cache-Control and Expires are set; Expires is ignored wherever Cache-Control is understood.
Harmless, but the Expires value is not the one in effect — do not tune it expecting a change.
/expires
- warningPermissions-Policy is not set.
Without it, embedded third-party frames inherit access to camera, microphone and geolocation prompts.
/permissions-policy
- warningReferrer-Policy is not set.
Without it, the full URL — including any path or query secrets — is sent to third-party origins.
/referrer-policy
- warningServer advertises "nginx/1.24.0".
Version information helps an attacker pick an exploit. It is not a vulnerability by itself.
/server
- warningCookie "session" has no SameSite attribute; browsers now default it to Lax.
/set-cookie/session
- warningmax-age is 1 day; preload lists require at least 180 days.
/strict-transport-security
- warningNo includeSubDomains, so a subdomain can still be reached over plain HTTP.
/strict-transport-security
What each header does
11| Header | Value | What it does |
|---|---|---|
| Date | Mon, 27 Jul 2026 09:14:22 GMT | When the response was generated. |
| Content-Type | text/html; charset=utf-8 | The media type of the body, and the character set the client should decode it with. |
| Cache-Control | no-cache, max-age=3600 | How long, and by whom, this response may be cached.max-age=3600 is 1 hour. |
| Expires | Mon, 27 Jul 2026 10:14:22 GMT | An absolute expiry time. Superseded by Cache-Control: max-age wherever both are present. |
| Etag | "3f8a9c21" | A version identifier for this body. The client sends it back as If-None-Match to revalidate. |
| Content-Security-Policy | default-src 'self'; script-src 'self' 'unsafe-inline' * | Restricts where scripts, styles and other resources may load from. |
| Strict-Transport-Security | max-age=86400 | Forces HTTPS for this host for the given duration.max-age=86400 is 1 day. |
| X-Content-Type-Options | nosniff | With `nosniff`, stops the browser guessing a content type other than the declared one. |
| Set-Cookie | session=abc123; Path=/; HttpOnly | Sets a cookie on the client. |
| Server | nginx/1.24.0 | The software serving the response. |
| Access-Control-Allow-Origin | * | Which origins may read this response from script. |
Not checked
the limits of a local validator- Whether the certificate is valid, or what TLS version was negotiated — none of that is in a header block.
- Whether the CSP actually matches the page's scripts. A policy can be perfect here and break the site.
- Request headers, and therefore anything that depends on what was asked for.
- Response bodies. A missing security header is not the same as a vulnerability.
Analysed in your browser — headers are never uploaded, which matters because a pasted block often contains a session cookie. For a whole session rather than one response, use the HAR File Analyzer.
About the HTTP Header Analyzer
This HTTP header analyzer explains a response header block and reports what is missing from it. Paste the output of curl -I, DevTools' raw headers view, or a HAR entry, and it names each header, flags the security headers that are absent, parses the Content-Security-Policy, checks cookie attributes, and finds cache headers that contradict each other.
It does not fetch the URL, and that is deliberate. Every other tool with this name takes a URL and fetches it server-side, which requires running a request-forwarding endpoint — and makes your target the first thing on this site that leaves the browser. The reframing costs you one paste and buys three things a fetching checker cannot do at all: it works on an authenticated response, on an internal host no hosted service can reach, and on a response you captured hours ago.
Findings are graded rather than listed flat. A missing HttpOnly on a CSRF token the front end must read is correct; on a session cookie it is a bug — so it is a warning with the reason attached, not an error. A Content-Security-Policy with unsafe-inline is an error, unless a nonce or hash is also present, in which case CSP3 browsers ignore unsafe-inline entirely and it is a deliberate fallback. Reporting that as a vulnerability is the kind of confidently wrong finding that gets a tool ignored.
Headers the tool does not recognise are listed as unchecked rather than passed over. That is the rule the other validators on this site follow, and it is what makes a clean verdict worth anything: it means everything known was checked, not that four headers were recognised and the rest ignored.
- Every header explained in plain language, not just the security-relevant ones — Content-Type, Cache-Control, ETag, Vary and Content-Encoding included
- Per-header explanations, with durations expanded — max-age=31536000 reads as 1 year
- Missing security headers reported with why each matters: CSP, HSTS, nosniff, Referrer-Policy, Permissions-Policy
- CSP parsed by directive, flagging unsafe-inline, unsafe-eval, wildcards and data: in script contexts
- Every CSP header checked, not just the first — browsers enforce all of them
- HSTS max-age checked against the preload minimum, with preload-without-includeSubDomains caught
- Per-cookie Secure, HttpOnly and SameSite checks, with repeated Set-Cookie handled separately
- Cache contradictions found: Expires shadowed by Cache-Control, no-cache with max-age, no-store with an ETag
How to use it
- Run curl -I https://example.com, or open DevTools → Network, click the request, and copy the raw response headers.
- Paste the whole block, status line included. The status line is optional but enables a few extra checks.
- Read the verdict, then the issues. Errors are things that are wrong; warnings are things that depend on context, and each says what that context is.
- Check the unchecked list. Anything there was not examined, so a clean verdict does not cover it.
- Fix the errors first — a missing Secure attribute or a SameSite=None without Secure is rejected by browsers outright.
Real-world use cases
Security & AppSec engineers
Run a CSP, HSTS and cookie-attribute audit against production response headers pasted from curl -I — including an authenticated endpoint or an internal host that a hosted security-header scanner cannot reach at all.
Backend developers
Work out why a cross-origin fetch fails despite an Access-Control-Allow-Origin header, or why a cached response keeps serving stale content — the per-header table and the cache-contradiction checks are built for exactly this, not only for a security scorecard.
Frontend developers
Look up what an unfamiliar response header actually does — Vary, Permissions-Policy, Content-Encoding — the same way you'd check MDN, but against the specific header block your app actually sent.
DevOps & platform engineers
Verify security and cache headers before and after a reverse-proxy or CDN configuration change, by pasting curl -I output from staging or an internal host straight into the tool.
QA engineers
Confirm Secure, HttpOnly and SameSite are set correctly on a staging deployment's cookies, before the same headers reach production where a mistake is far more expensive to catch.
Examples
A CSP that defeats itself
content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline' *
script-src allows 'unsafe-inline', which defeats most of the protection CSP provides. script-src allows any origin (*), which makes the directive decorative.
Both are errors. A policy that allows inline script and any origin is doing almost nothing except costing bytes.
A nonce changes the verdict
content-security-policy: script-src 'self' 'unsafe-inline' 'nonce-abc123'
Warning: CSP3 browsers ignore 'unsafe-inline' when a nonce or hash is present.
A warning, not an error — this is the standard CSP2 fallback pattern and is intentional in most real policies.
HSTS that will not preload
strict-transport-security: max-age=86400; preload
max-age is 1 day; preload lists require at least 180 days. preload requires includeSubDomains; without it the host will be rejected from the preload list.
Both problems are silent — submission simply fails, and the header keeps looking correct in the response.
Cache headers that disagree
cache-control: no-cache, max-age=3600
no-cache forces revalidation, so max-age has no effect here.
Not an error, and worth knowing: tuning the max-age value will change nothing until the no-cache is removed.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Line N is not a header | Something other than a Name: value pair — usually a curl progress line, a request header block, or wrapped text. | Paste the response headers only. curl -I gives exactly this; curl -v mixes in the request and TLS handshake. |
| Refused to execute inline script because it violates CSP | The page has inline script and the policy has no nonce, hash or unsafe-inline for it. | Add a nonce to the policy and to the script tag. Adding unsafe-inline works and gives up most of the protection — which this tool reports as an error for that reason. |
| Cookie rejected because it has the SameSite=None attribute but is missing the Secure attribute | SameSite=None requires Secure. Browsers reject the cookie outright rather than downgrading it. | Add Secure. If the cookie does not need cross-site sending, use SameSite=Lax instead — it is the default and safer. |
| The site is served over HTTPS but is still reachable over HTTP | No HSTS, or HSTS without includeSubDomains so subdomains are unprotected. | Set max-age to at least 180 days with includeSubDomains. Roll it out with a short max-age first — HSTS is hard to undo once browsers have cached it. |
| A cross-origin fetch fails despite Access-Control-Allow-Origin: * | A wildcard origin cannot be combined with credentials. Browsers reject the pair. | Echo the specific requesting origin instead, and add Vary: Origin so caches do not serve one origin's response to another. |
Frequently asked questions
›Why does it not just fetch the URL for me?
Because that needs a server, and a server that fetches arbitrary URLs on request is a request-forwarding endpoint with a real abuse surface. It would also make this the only tool on the site that transmits your input. Pasting costs one extra step and lets the tool work on authenticated responses and internal hosts, which no hosted checker can reach.
›Are my headers uploaded anywhere?
No. Everything is parsed and analysed in your browser, which matters directly here — a pasted response header block routinely contains a Set-Cookie with a live session token.
›Does a clean result mean the site is secure?
No, and the tool is explicit about it. Headers are one layer. A perfect header block sits happily in front of an application with an authentication bug, and a CSP can be flawless here and still break the site it protects. The "not checked" panel lists what a header block cannot tell you.
›Why is a missing HttpOnly only a warning?
Because it is sometimes correct. A CSRF token the front end must read cannot be HttpOnly. On a session cookie it is a real problem. The tool cannot tell which cookie is which, so it reports the fact with the context rather than guessing at the severity.
›Should I remove the Server header?
It is worth doing and it is not a vulnerability — the tool says so in the hint rather than inflating it. Version numbers make target selection easier for automated scanning; removing them does nothing about the underlying issue but does reduce noise.
›What is the difference between Cache-Control and Expires?
Expires is the HTTP/1.0 header and gives an absolute time; Cache-Control gives a relative lifetime and takes precedence wherever both are present. Setting both is harmless but misleading, because the Expires value is not the one in effect — which is why it is flagged.
›Which security headers actually matter most?
Content-Security-Policy by a distance — it is what converts an XSS bug into a non-event. Then HSTS, which closes the plain-HTTP first request. X-Content-Type-Options is a one-word header with no downside. Referrer-Policy and Permissions-Policy matter, but less, and are cheap to add.
›Is this only for a security audit, or does it help with general header debugging?
Both, and the second is most of what the per-header table is for. Every header in the pasted block gets a plain-language explanation — Content-Type, Cache-Control, ETag, Vary, Content-Encoding — not only the security-relevant ones. Paste a response you are debugging for a caching bug or a CORS failure and the table and the cache-contradiction checks apply just as much as they do to a CSP audit.
Last updated