HTTP Header Checker

Why I Started Checking HTTP Headers on Every Site I Build

I used to think HTTP headers were something only senior backend engineers worried about. Then I deployed a client's e-commerce site, felt pretty good about myself, and ran it through an HTTP Header Checker on a whim. The results were genuinely embarrassing. No Content-Security-Policy. No X-Frame-Options. HSTS not configured. The server was advertising its exact version number in the Server header — basically handing attackers a shopping list.

That was the moment I started treating header audits the same way I treat password hygiene: non-negotiable, not optional, and something I do before considering any project "done."

What an HTTP Header Checker Actually Does

When your browser loads a webpage, the server sends back a set of response headers alongside the HTML content. Most users never see these — they live behind the scenes in the network tab of DevTools. But they carry enormous weight for security, privacy, caching behavior, and how browsers interpret your content.

An HTTP Header Checker is a tool that makes a request to any URL you give it and displays every response header the server returns, laid out in a readable format. Some tools just show the raw header dump. Better ones flag missing security headers, grade your configuration, and explain what each header does and why it matters.

The most useful checkers I've worked with break headers into categories: security headers, caching headers, content-type declarations, and server information disclosures. That last category is where most sites quietly leak details they shouldn't.

The Headers That Actually Matter for Security

After running dozens of audits across client projects and my own apps, these are the headers I always check first:

• Strict-Transport-Security (HSTS): Forces browsers to always use HTTPS, even if a user types the HTTP version of your URL. Without this, you're vulnerable to SSL stripping attacks. The value should include a long max-age (31536000 seconds is standard) and ideally includeSubDomains.
• Content-Security-Policy (CSP): One of the most powerful and most commonly misconfigured headers. It tells the browser which sources of scripts, images, and styles are legitimate. A missing or overly permissive CSP is an open door for cross-site scripting attacks.
• X-Frame-Options: Prevents your site from being embedded in an iframe on another domain — the classic defense against clickjacking. Should be set to DENY or SAMEORIGIN.
• X-Content-Type-Options: Set to nosniff, this stops browsers from trying to guess the content type of a response. Simple to add, frequently missing.
• Referrer-Policy: Controls how much referrer information is sent when a user clicks a link leaving your site. strict-origin-when-cross-origin is a solid default that balances analytics usefulness with privacy protection.
• Permissions-Policy: The newer replacement for Feature-Policy, lets you control which browser features (camera, microphone, geolocation) your site can access. Most sites don't set this at all.

The Privacy Problem Nobody Talks About: Information Disclosure Headers

Security discussions usually focus on what headers you should add. But some of the most important findings from an HTTP Header Checker are about what you should remove.

The Server header is the worst offender. I've seen production servers returning values like Apache/2.4.51 (Ubuntu) — exact version numbers sitting in every single response. That's a gift to anyone scanning for known vulnerabilities in that specific version. The fix is a one-liner in your server config, but most developers never think to do it because the server adds it automatically and nobody checks.

Similarly, X-Powered-By headers often expose your backend technology — PHP/8.1.2, Express, whatever framework you're running. When I ran the header checker on a SaaS app I was working on, it revealed that every API response was advertising the exact PHP version. We stripped it out in about three minutes. The point isn't that knowing you run PHP is some devastating secret — it's that you're making it marginally easier for automated scanners to identify and target you, for no benefit whatsoever.

How I Actually Use the Tool in My Workflow

My process isn't complicated, but it's consistent. I run an HTTP Header Checker at three specific points:

1. Before any public launch. After deploying to a staging environment that mirrors production, I run a full header audit. This catches configuration issues before real users (or real attackers) ever show up.
2. After any server or infrastructure change. Nginx configuration changes, moving to a new host, switching CDN providers — any of these can silently reset or override headers. I've had Cloudflare rules that were supposed to inject security headers stop working after a configuration update, and I only caught it because I checked.
3. As a quick audit on competitor or reference sites. When I'm researching how other sites in a space handle security, running their URLs through an HTTP Header Checker is a fast way to benchmark. It's also a sobering reminder that "that big popular site" often has surprisingly basic security gaps.

Reading a Real Header Audit — What You'll See

When you paste a URL into an HTTP Header Checker and hit analyze, you'll typically see output like this for a well-configured site:

The response starts with the HTTP status code — 200 for a successful response, 301 or 302 for redirects (worth noting: if you enter an HTTP URL and get redirected to HTTPS, the checker should follow that redirect and show you the headers for the final destination, not just the redirect response). Then comes the actual header list.

A properly secured response might show strict-transport-security: max-age=31536000; includeSubDomains; preload, a well-structured content-security-policy directive, x-content-type-options: nosniff, and a clean referrer-policy. What you won't see is the server version or framework details.

A poorly configured site will show gaps — the checker will either display a blank where those headers should be, or explicitly flag them as missing. Good tools color-code these: green for headers that are present and well-configured, yellow for headers that exist but could be strengthened, red for missing security-critical headers.

One Thing Most People Miss: Caching Headers

Security aside, HTTP headers also control how aggressively browsers and CDNs cache your content. The Cache-Control and Vary headers determine whether a CDN serves stale content to users, and whether sensitive pages (like account dashboards or checkout flows) get inappropriately cached.

I've seen authenticated pages returning Cache-Control: public, max-age=3600 — which means the CDN might serve one user's session page to a different user. Running an HTTP Header Checker on your login-protected routes (using curl or a tool that supports custom request cookies) can surface these issues before they become incidents.

Making It a Habit, Not a One-Time Check

The thing about HTTP headers is that they're invisible during normal development. Nobody's going to notice a missing X-Frame-Options header while clicking around your app. The problems only surface when something goes wrong — and by then, it's too late to feel good about having "shipped."

Building the header check into deployment checklists, pre-launch reviews, and periodic audits costs almost nothing in time. The tool itself is free and takes about ten seconds to return results. What it gives you is a concrete, actionable snapshot of something that's genuinely hard to keep track of any other way.

I don't think of it as a security tool exactly — I think of it as a mirror. It shows you what your server is actually saying to the world, not what you think it's saying. And more often than not, there's a gap between those two things worth closing.