HTTP Header Analyser

about this tool

Paste the response headers and get the three things the raw list does not give you: what the security headers actually do, what the caching headers add up to, and whether the cookies are safe.

Nothing is fetched

Most header checkers make the request themselves. That sounds more convenient and answers a different question: what a server returns to a datacentre, with no cookies, no session and no geography. The response you are debugging is the one you received.

So this reads what you paste. Which also means your session cookie stays out of somebody else's logs — and a Set-Cookie line is exactly the sort of thing people paste into a checker without thinking.

What gets graded, and what does not

Each check says what the header is for, what yours is set to, and what to change. No letter grade: a B tells you nothing without the rubric, and rubrics are where tools smuggle in opinions.

Content-Security-Policy is marked weak if it carries unsafe-inline, unsafe-eval or a wildcard script source. Each of those lets injected script run anyway, so the policy is doing far less than its presence suggests.

Strict-Transport-Security is graded on its max-age. Below six months is weak — a browser that has forgotten the header is back to an interceptable first request, and preload lists will not take it.

Frame protection accepts either frame-ancestors in a CSP or the older X-Frame-Options, and says which you have.

X-XSS-Protection is deliberately absent. Every current browser ignores it, and in the versions that honoured it the filter could be turned against a page. Tools that still ask for it are repeating advice that expired years ago.

Cookies

Secure and SameSite are wrong to leave off any cookie.

HttpOnly is not. A theme or locale cookie exists precisely so the page can read it, and marking every such cookie as a fault would make the list mean nothing. So a missing HttpOnly is a problem on a cookie whose name reads like a session, and a note on one that does not.

SameSite=None without Secure is called out on its own, because browsers reject that combination outright — the cookie is not set at all.

Caching, in words

no-store, no-cache and max-age=0 look similar and mean three different things. The caching section says what the headers you have add up to, and flags a long max-age without a versioned URL — the setting that works beautifully until you need to ship a fix.

Version numbers

Server: nginx/1.24.0 and X-Powered-By are called out when they carry a version. Neither does anything for a visitor, and both tell somebody scanning for a known vulnerability exactly which one to try.

Nothing leaves the browser

The headers are parsed where you pasted them. That matters more here than on most pages, because a response header block routinely contains a Set-Cookie line with a live session in it — which is exactly the thing people paste into a checker without thinking about where it goes.

For the request that produced these headers, cURL converter turns it into code, and the HAR viewer reads a whole session's worth at once.

questions

How do I get the response headers?

Run curl -I against the URL, or open the network tab, click the request and copy the response headers. Paste the block here — a status line on top is fine and is read too.

Why does this not fetch the URL itself?

Because a checker that makes its own request sees what a server returns to a datacentre with no cookies and no session, which is rarely the response you are debugging. Pasting what you actually received keeps the answer about your request — and keeps your session cookie out of somebody else’s logs.

What is a good Strict-Transport-Security max-age?

At least 15552000, which is six months and the minimum preload lists accept. Anything shorter is graded weak here: a browser that has forgotten the header is back to an interceptable first request.

Why is my CSP marked weak when it is set?

Because unsafe-inline or unsafe-eval lets injected script run anyway, and a wildcard script source permits code from anywhere. A policy with either of those is doing much less than it appears to.

Why is a missing HttpOnly not always flagged?

Because a theme or locale cookie exists so the page can read it. HttpOnly is a fault on a cookie whose name suggests a session, and a note on one that does not — a list where every row is flagged tells you nothing.