HTTP Header Check: Paste a Response and Audit It Offline

Why this tool parses instead of fetching

Most header checkers ask for a URL and fetch it. That design has a consequence the field usually does not mention: the tool becomes a way to send requests from its own infrastructure to any address a visitor types, which is both a misuse risk and a claim the tool cannot support — the response it fetches is the one its server received, not the one your browser receives.

This tool does the other thing. You paste the response you already have, and the audit runs on the text. The result is the same, the tool cannot be used to probe a third party, and the response being evaluated is genuinely the one from your own request rather than from somewhere else on the network.

What each of these headers is actually for

Transport security headers tell a browser to refuse insecure connections in future. The strict transport security header is the one that matters most, and its important parameter is the maximum age: a short value means the protection lapses between visits, so the first request of a session can still be intercepted and redirected. The report distinguishes a long maximum age from a short one rather than simply marking the header present.

Content security policy restricts where scripts and other resources can come from, and it is the main control that limits the damage of an injected script. Its effectiveness lives entirely in its value, which is why the audit names the specific weaknesses it finds: permitting inline scripts, permitting dynamic evaluation, and omitting a framing restriction each remove a distinct part of the protection.

Content type and frame options are narrow controls with clear jobs. The first stops a browser from guessing a content type, which prevents a file uploaded as text from being executed as script. The second blocks framing, and although a content security policy framing directive supersedes it, older clients still read the older header.

Referrer policy controls how much of the current address is sent along with a request to another site. Without it, full addresses leak to third parties, which matters more than it sounds when addresses contain identifiers. Permissions policy switches off browser features a page does not use, reducing what a successful injection could reach.

Cookie flags decide whether a session identifier can be read by scripts or sent in a cross-site context. They are evaluated only if the response sets a cookie, and the report names each flag that is missing rather than reporting a generic failure.

Reading the result column rather than the presence

A checklist that only records presence makes the same mistake a cleanliness score makes: it compresses a value that carries meaning into a binary that does not. A strict transport security header with a maximum age of a day is present and nearly useless. A content security policy that permits inline scripts is present and provides a fraction of what it appears to.

So each row in the audit reports what was found and quotes the part that decides the outcome. The version-disclosure check is the clearest example: a header naming the server software and its version is not a vulnerability, but it tells an attacker which known issues to try first, and that is a fact worth having rather than a defect worth failing.

What an audit of one response cannot tell you

It cannot tell you what an attacker would receive. A site can return a fully hardened response to a careful request and a different one to a request that looks automated, and reading one pasted block cannot detect that. It also cannot tell you whether the response you pasted was the one that serves the content; redirects, caching layers and front-end proxies each can add or drop headers.

It cannot tell you whether a site is safe. Headers are one layer of defence against specific classes of attack, and their absence has different consequences depending on what the site does. A static page with no cookies, no forms and no user input has far less to protect than an application with sessions.

It cannot see anything above or below the response itself. Whether the certificate was valid, whether the connection was encrypted and whether a request was redirected are all outside the header block. The certificate-authority records that govern issuance are on the SSL and CAA check, and the order to work through when a page simply does not load is set out in the network guide.

Where the response you pasted contains an address you want to understand, the IP check reports its network and family, and where the question is whether a name resolves at all, DNS lookup is the direct answer.