HTTP Headers Checker

What response headers are

Every HTTP response has two parts: a set of headers, then the content. The headers arrive first and decide almost everything about how the browser treats what follows — whether it may be cached, whether it may be framed, which scripts are allowed to run, how much of the current URL leaks to the next site. The page is what you see; the headers are what the browser obeys.

That makes them the fastest way to answer a whole class of questions. Is the CDN caching this? Did the HSTS header actually ship? Is the redirect a 301 or a 302? Which server is really answering? None of that is visible in the page itself.

Status codes at a glance

The security headers, one by one

These are the headers that change what an attacker can do to your visitors. None of them is mandatory, and a site that omits some is not automatically insecure — but each one closes a specific, well-documented attack, and it is worth knowing which ones you have chosen to leave open.

Strict-Transport-Security

HSTS tells the browser to use HTTPS for this host for the next max-age seconds, no matter what the user types or what a link says. Without it, a visitor's very first request can still go out over plaintext http:// — and that request, before your redirect to https:// has any chance to run, is the one an attacker on the same network intercepts. Adding includeSubDomains extends the rule to every subdomain, which is what makes a stray unencrypted dev.example.com stop being a hole.

Content-Security-Policy

CSP is the strongest defence against cross-site scripting available in the browser. It enumerates where script, style, images, frames and connections may legitimately come from, so an injected <script> from a comment field or a compromised third-party library simply does not execute. It also carries frame-ancestors, which is the modern replacement for X-Frame-Options. Start with Content-Security-Policy-Report-Only on a real site: a policy written blind will break something.

X-Frame-Options and frame-ancestors

Both control who may load your pages inside a frame. The attack they stop is clickjacking: your real page, invisible, layered under something that persuades the visitor to click where the dangerous button happens to be. X-Frame-Options: DENY or SAMEORIGIN is the old form; frame-ancestors in CSP is the current one and is strictly more capable. Having only the CSP directive is correct, not a gap.

X-Content-Type-Options

One value, nosniff, and it does one thing: stops the browser second-guessing the Content-Type you declared. Without it a browser may decide that an uploaded file which claims to be an image is really HTML, and run the script inside it — on your origin, with your cookies. It is a single line with essentially no compatibility cost.

Referrer-Policy

Controls how much of the current URL is handed to the next site when a visitor follows a link or loads a third-party resource. The default on many sites sends the full URL to same-protocol destinations, and full URLs frequently contain more than their authors think — reset tokens, internal identifiers, search terms. strict-origin-when-cross-origin is a sensible baseline.

Permissions-Policy

Declares which browser features your pages, and anything you embed, are permitted to use: camera, microphone, geolocation, payment. It is chiefly a way of guaranteeing that a third-party frame cannot ask your visitors for permissions on your behalf.

The cross-origin trio

Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy together give a page a genuinely isolated browsing context, which defends against cross-window attacks and the Spectre family of side channels. COOP and CORP are cheap and worth setting. COEP is intrusive — it requires every embedded resource to opt in — so it is normally only worth the trouble if you need the APIs that cross-origin isolation unlocks.

Redirects, and why the chain matters

A bare domain rarely answers directly. example.com becomes https://example.com becomes https://www.example.com, and the header you are hunting for lives at the end of that chain rather than at the start. Seeing every hop is often the point of the exercise: a chain that redirects http to www over plaintext before finally reaching https has an interception window in the middle, and a chain that is one hop longer than it needs to be costs every visitor a round trip.

Why the check is made from IPGet's server

Your browser can already show you response headers in its developer tools, so why ask a server to do it? Because your browser's answer is entangled with you. It sends your cookies, your session, your extensions, your language preferences and your address. It uses your ISP's path and your local cache. What it shows you is what you receive, which is precisely what you cannot use to answer "what does a stranger see?"

A request from IPGet's server is anonymous and reproducible. It carries a fixed User-Agent, an Accept header and nothing else — no cookies, no Authorization, no referrer, nothing forwarded from your own request. That is the same view a search-engine crawler, an uptime monitor or a first-time visitor gets, and it is the view worth debugging.

How this is kept safe

Any feature that makes a server fetch a URL a stranger supplies is a server-side request forgery primitive, and one that follows redirects is the sharpest version of it: the redirect target is chosen by the site being checked, not by us and not by you. A single Location: http://169.254.169.254/ is all it takes to turn a naive header checker into a cloud-credential leak.

The checker therefore applies the full set of rules to every hop, not just the first:

• Only http: and https: are followed, and only on ports 80, 443, 8080 and 8443. A redirect to file:, gopher: or an arbitrary port is refused outright.
• URLs carrying a username or password are refused rather than stripped, and are never logged anywhere.
• Every hop is resolved through the same destination guard the port checker uses. If any address a host resolves to is private, loopback, link-local, carrier-NAT or a metadata endpoint, the whole request is refused — not merely that address.
• The connection is made to the resolved address, never to the host name. Handing the name to the socket would resolve it a second time, and whoever controls that zone could answer with a public address for the check and 127.0.0.1 a moment later. That is DNS rebinding, and pinning the validated address is the only reliable defence. The host name is used only as the TLS server name and the Host header.
• A redirect to a private destination is refused exactly as a typed one would be, because the loop runs the whole validation again for each hop rather than trusting the chain it is already in.
• HEAD is used first so there is usually no body at all. When a server refuses HEAD, one GET is retried and the socket is destroyed as soon as the byte cap is reached — the body is counted and discarded, never stored and never returned.
• Redirects are capped, every hop has a timeout, the whole chain has a shorter overall budget, and requests are rate limited per address.

Related: check the certificate behind a host with the SSL Checker, confirm a service is reachable at all with the Port Checker, or look at the records behind the name with the DNS Checker.