How to Check HTTP Security Headers: A Practical Guide

Why HTTP Security Headers Matter

HTTP security headers are server responses that tell the browser how to behave when handling your site's content. They are one of the cheapest, fastest defenses you can deploy against XSS, clickjacking, MIME sniffing, protocol downgrade, and data leakage attacks. The catch? They only work if they're actually present, correctly configured, and not silently overridden by a CDN or framework.

This guide walks through how to check HTTP security headers on any site you own or audit, what each header should look like, and how to fix the most common issues developers find on the first scan.

The Core Headers You Should Be Checking

Before running any tool, know what you're looking for. These are the headers that should appear on virtually every modern web response:

• Strict-Transport-Security (HSTS) — forces HTTPS for a defined period.
• Content-Security-Policy (CSP) — controls which scripts, styles, and resources can load.
• X-Frame-Options or frame-ancestors in CSP — prevents clickjacking via iframes.
• X-Content-Type-Options — stops MIME sniffing (nosniff).
• Referrer-Policy — limits what's leaked in the Referer header.
• Permissions-Policy — restricts browser features like camera, geolocation, and USB.
• Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy — isolate your origin for Spectre-class protection.

How to Check HTTP Security Headers: Three Methods

1. Using curl from the Command Line

The fastest way to inspect headers locally is curl. Run:

curl -I -L https://example.com

The -I flag requests headers only, and -L follows redirects so you see the final response. For a verbose look at the full handshake and any intermediate hops, use:

curl -sSL -D - https://example.com -o /dev/null

Look at every line in the response. If Strict-Transport-Security, Content-Security-Policy, or X-Content-Type-Options are missing, that's an immediate finding.

2. Using Browser DevTools

Open Chrome or Firefox DevTools, switch to the Network tab, reload the page, and click the document request. Under Headers > Response Headers, you'll see every header the server returned. This is useful because it shows what the browser actually received after any CDN or proxy modifications — which sometimes differs from what your origin server sent.

3. Using an Online Header Checker

Command-line tools are precise but slow if you're auditing dozens of URLs or want a graded report. The AXOX Hub HTTP Header Checker fetches your URL, lists every response header, and flags missing or weak security headers in seconds. It's the easiest way to share a quick audit with a client or a teammate who doesn't live in a terminal.

Reading the Results: What Good Looks Like

Strict-Transport-Security

A solid HSTS header looks like:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Anything under max-age=15552000 (six months) is generally too short. Without includeSubDomains, attackers can target a subdomain over plain HTTP.

Content-Security-Policy

CSP is the most powerful and the most frequently misconfigured header. A reasonable starting policy:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'

Red flags to watch for:

• 'unsafe-inline' in script-src — defeats most XSS protection.
• 'unsafe-eval' — needed only for very specific frameworks; avoid if possible.
• Wildcard sources like * or broad CDN domains.
• Missing object-src 'none' or base-uri 'self'.

X-Frame-Options vs frame-ancestors

Modern best practice is to use frame-ancestors 'none' in your CSP. X-Frame-Options: DENY is still useful as a fallback for older browsers but is technically obsolete.

Referrer-Policy and Permissions-Policy

Reasonable defaults:

Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=()

A Step-by-Step Audit Workflow

1. List your endpoints. Don't just check the homepage — include API routes, login pages, and admin paths. Headers often differ.
2. Run a baseline scan. Use curl or the AXOX Hub HTTP Header Checker to capture current state. Save the output.
3. Identify gaps. Compare against the core list above. Note any missing headers or weak values.
4. Test CSP in report-only mode first. Deploy Content-Security-Policy-Report-Only with a reporting endpoint before enforcing. This catches inline scripts and third-party resources you forgot about.
5. Fix at the right layer. Set headers in your web server (Nginx, Apache, Caddy), reverse proxy, or CDN — not just in application code, which can be bypassed for static assets.
6. Re-scan. Verify every header now appears with the expected value on every endpoint.
7. Add headers to CI. Write a simple curl-based test that fails the build if a required header is missing.

Common Mistakes to Avoid

• Setting headers only on HTML responses. JSON APIs need X-Content-Type-Options: nosniff and a restrictive CSP too.
• Duplicating headers. Some stacks set the same header twice with different values — browsers may pick the wrong one.
• Forgetting the CDN. Cloudflare, Fastly, and others can strip, add, or override headers. Always check the final response from the public internet, not localhost.
• Using unsafe-inline as a permanent solution. Refactor inline scripts to external files or use nonces and hashes.
• Setting HSTS preload prematurely. Once you submit to the preload list, removal takes months. Test thoroughly first.

Run Your First Scan in 30 Seconds

Knowing how to check HTTP security headers is a foundational skill — and once you've audited one site, you'll start spotting issues on every site you visit. Start with the URL you care about most.

Run a free, instant audit with the AXOX Hub HTTP Header Checker at axoxhub.com. Paste your URL, get a full breakdown of present and missing security headers, and turn the findings into a punch list for your next deploy.