HTTP Response Header Inspector

What the HTTP response tells you

Every HTTP response has headers that describe the response — content type, caching policy, security rules, server software, and dozens of others. This tool fetches any URL and shows you everything the server sends back.

Headers worth checking

• Server / X-Powered-By — what software is running. Server fingerprinting.
• Content-Type — what the response actually is (HTML, JSON, image, etc.).
• Cache-Control / ETag / Last-Modified — caching behavior.
• Strict-Transport-Security (HSTS) — forces future requests to HTTPS. Critical for security.
• Content-Security-Policy (CSP) — restricts which resources the page can load.
• X-Frame-Options / X-Content-Type-Options — anti-clickjacking and MIME-sniffing protection.
• Set-Cookie — cookies being set, with their Secure/HttpOnly/SameSite flags.
• Access-Control-Allow-Origin — CORS policy.
• Server-Timing — backend performance metrics.

What missing headers tell you

Sometimes the absence of a header matters more than its presence. No HSTS header on a banking site? Big red flag. No CSP on a site that serves user content? Vulnerable to XSS exfiltration. Modern security headers should be present and properly configured on production sites.

What HTTP headers actually reveal about a site

When I'm auditing a site — for a customer, for the tools on this site, or just because I'm curious — HTTP headers are almost always the first thing I look at. They're the metadata a web server sends with every response, and they carry a surprising amount of information about how the site is configured, what security posture it has, and sometimes what technology stack it's built on.

Most of this data is intended for browsers to consume. Cache directives tell the browser whether to store responses locally. Security headers tell the browser what content is allowed to load from where. Content negotiation headers describe encoding, language, and format. Some of the headers are internal server implementation details that leaked out because someone forgot to strip them.

The security-focused headers I check first

Strict-Transport-Security (HSTS)

HSTS tells the browser to only ever connect to this site over HTTPS. Once the browser sees the header once, it refuses to make plain-HTTP requests to the same host for the duration specified in the header — even if the user types http:// explicitly or clicks a plain-HTTP link. This prevents SSL-stripping attacks where a middle-attacker downgrades the connection from HTTPS to HTTP.

A well-configured HSTS header looks like Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. The max-age is one year in seconds. IncludeSubDomains extends the protection to every subdomain. Preload asks Google to add the site to Chrome's HSTS preload list, which means browsers enforce HSTS even on first visit before they've seen the header at all. Not every site can safely use these flags — includeSubDomains breaks if there's a subdomain that must serve plain HTTP — but the more of them you can enable, the safer the site is.

Missing HSTS on a site that serves HTTPS is a common oversight. It doesn't immediately break anything — the site still works — but it leaves users vulnerable to downgrade attacks on their first connection. Adding the header is usually a one-line configuration change.

Content-Security-Policy (CSP)

CSP is the most powerful and most confusing security header. It tells the browser what sources of scripts, styles, images, fonts, frames, and other resources are allowed to load on this page. A well-configured CSP dramatically limits the impact of XSS vulnerabilities — even if an attacker manages to inject a script tag, the browser refuses to execute it because the source isn't in the allowlist.

The trade-off is that CSP breaks legitimate functionality until it's tuned. Inline scripts fail. Third-party analytics scripts fail. Even things like dynamically-injected style tags might fail. Rolling out CSP on an existing site requires a lot of testing and often a period of running the policy in report-only mode (where violations are logged but not blocked) before enforcing it.

When I audit a site's CSP, I'm looking for common weaknesses: 'unsafe-inline' in the script-src directive (which defeats most of the protection), 'unsafe-eval' (also bad), overly-broad domains in the allowlist (like allowing all of *.googleapis.com when only specific subdomains are needed), missing directives (each type of resource has its own directive and forgotten types default to permissive behavior).

X-Frame-Options

An older header that prevents your site from being embedded in an iframe on another site. This blocks clickjacking attacks where an attacker overlays your site's login form or checkout page inside their own frame. The header has three values: DENY (never allow embedding), SAMEORIGIN (only allow same-origin embedding), or ALLOW-FROM (allow specific origins, though this value is deprecated).

Modern CSP's frame-ancestors directive supersedes X-Frame-Options, but both are still commonly used. Sites that don't need to be embedded anywhere should send DENY.

Referrer-Policy

Controls what information the browser sends in the Referer header when following a link away from your site. Default browser behavior sends the full URL, which can leak internal URLs to external sites. A policy of strict-origin-when-cross-origin sends only the origin (like https://example.com/) when navigating to a different origin, and nothing at all when downgrading from HTTPS to HTTP.

Not setting Referrer-Policy explicitly means the browser uses its default, which varies between browsers and browser versions. Setting it explicitly is a small win for user privacy and predictability.

Permissions-Policy

Formerly known as Feature-Policy. Controls which browser features (camera, microphone, geolocation, USB access, autoplay, etc.) are allowed on the page. A well-configured Permissions-Policy denies access to features the site doesn't need, which prevents third-party embedded content from silently requesting permissions.

Headers that leak information

Server

Traditionally the Server header identifies the web server software: Server: nginx/1.24.0, Server: Apache/2.4.58 (Ubuntu), Server: Microsoft-IIS/10.0. This is genuinely useful for the operator to know what they're running, but it's also useful to an attacker who wants to target known vulnerabilities in specific versions. Stripping the Server header (or setting it to a generic value) is a modest hardening step.

Sites hosted behind Cloudflare, Fastly, or another CDN will show the CDN's Server header (usually cloudflare or Fastly) rather than the origin's, which incidentally hides the origin technology.

X-Powered-By

Set by many application frameworks by default. X-Powered-By: PHP/8.2.0. X-Powered-By: Express. X-Powered-By: ASP.NET. Same reasoning as Server — useful diagnostic information for the operator, and information leakage from a security perspective. Most frameworks let you disable this header with a configuration setting.

X-AspNet-Version, X-AspNetMvc-Version

Specific to Microsoft .NET applications. Reveals the exact .NET framework version, which is very useful information for someone trying to identify vulnerabilities. Should be stripped in production.

Via

Added by proxies and gateways along the request path. Shows what proxy processed the response and sometimes what version of the proxy software. Cloudflare doesn't add this. Some enterprise proxies do.

Caching headers matter more than you think

Cache-Control

The primary header for controlling how browsers and intermediate caches store responses. Values like public, max-age=3600 mean anyone can cache this for an hour. private, no-cache means individual browsers can cache but must revalidate before using, and shared caches shouldn't store. no-store means don't cache at all — even in memory.

Wrong cache-control values cause weird bugs. If a login page has max-age=3600, users see cached logged-out versions of the page after logging in. If an API returns no-store for every response, performance is worse than it needs to be. Setting the right cache-control for each type of response is one of those quiet, unsexy performance wins that legitimately makes a site feel faster.

ETag and Last-Modified

Enable conditional requests. When a browser has a cached copy and the cache has expired, it sends the ETag or Last-Modified value back to the server. If the server sees that the resource hasn't changed, it returns 304 Not Modified with no body — saving bandwidth. Correct ETag generation is one of those small-detail things that separates a well-tuned server from a mediocre one.

Content headers to check

Content-Type

Tells the browser how to interpret the response body. Wrong content-type causes browsers to guess (a process called MIME sniffing), which can lead to security bugs. Serving user-uploaded content with a specific content-type and X-Content-Type-Options: nosniff prevents the browser from second-guessing the type.

Content-Encoding

Indicates compression. gzip, br (Brotli), and zstd are the common values in 2026. Brotli is now standard on most CDNs and produces smaller payloads than gzip for the same content. If you see uncompressed responses on a modern CDN-hosted site, someone missed a configuration.

Content-Length

The size of the response body in bytes. Occasionally useful for diagnostic purposes — if a browser complains about a truncated response, comparing content-length with actual received bytes tells you whether the truncation happened in transit or on the server.

Cookies and Set-Cookie

Set-Cookie headers deserve their own audit. Cookies with sensitive values should have the Secure flag (only sent over HTTPS), the HttpOnly flag (not accessible to JavaScript, preventing XSS-based theft), and the SameSite attribute (controls when the cookie is sent on cross-site requests). Missing any of these on a session cookie is a security finding.

Non-standard headers you'll see in the wild

Every CDN and framework adds its own headers. Cloudflare adds CF-Ray (a unique request ID useful for correlating logs) and CF-Cache-Status (whether the response came from Cloudflare's cache). Fastly adds x-served-by and x-cache. AWS CloudFront adds x-amz-cf-id and x-amz-cf-pop. These are useful for troubleshooting but not security-relevant.

Some sites add custom headers for developer curiosity. Reddit famously used to send X-You-Should-Work-Here-Instead as a recruiting message. GitHub sends x-github-request-id. Whether these are useful or just noise depends on the operator's goals.

Common findings when I audit a site

HSTS missing or short max-age

Extremely common. Adding HSTS is one line of configuration and dramatically improves the site's HTTPS posture. If max-age is under a year, either the operator is uncertain and hedging or someone copied a tutorial value without thinking. Recommendation: max-age=31536000 with includeSubDomains once you're sure all subdomains support HTTPS.

No CSP at all

Even more common. CSP is hard to roll out, and many sites just don't bother. The impact is that XSS bugs are more severe than they need to be. If you can't roll out a strict CSP, a permissive one is still better than nothing — at minimum, deny inline scripts and require HTTPS for all resources.

Server header exposing exact version

Common on self-hosted sites. Trivial to fix in most web server configs. Doesn't provide meaningful protection against sophisticated attackers who can fingerprint the site other ways, but reduces the noise from opportunistic scanners.

X-Powered-By set to specific framework version

Same as above. Application framework should be configured to suppress this.

Missing X-Content-Type-Options: nosniff

Especially important on sites that serve user-uploaded content. This one-line header prevents a whole class of MIME-confusion attacks.

Session cookies without HttpOnly and Secure flags

Common security-scanner finding. Both should always be set on session cookies unless there's a specific reason not to (and there almost never is).

Related tools on this site

If you want to inspect a site's TLS certificate along with its headers, the SSL/TLS Cert Inspector pulls the certificate chain and shows the subject, issuer, validity period, key size, and signature algorithm. Combining headers-and-cert inspection gives you a fairly complete security snapshot.

If you're auditing a domain more broadly (not just a single URL), the Domain Infrastructure tool shows all DNS records and identifies who owns the IP addresses each record points at. Useful for understanding "is this site actually hosted where it claims to be."