UseToolSuite UseToolSuite

HTTP Header Analyzer

Analyze HTTP response headers for security best practices. Check Content-Security-Policy, HSTS, X-Frame-Options, and more — with scores and recommendations.

Last updated

HTTP Header Analyzer is a free, browser-based tool from UseToolSuite's Network & API Tools collection. All processing happens locally on your device — your data is never uploaded to any server. Use the tool below, then scroll down for detailed documentation, frequently asked questions, and related resources.

Advertisement
Paste HTTP headers and click Analyze to see results.

What is HTTP Header Analyzer?

HTTP Header Analyzer is a free tool that evaluates HTTP response headers for security best practices. Paste your server's response headers and instantly get a security score, detailed recommendations for missing or misconfigured security headers, and descriptions of every header present. It checks for Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy.

When to use it?

Use this tool during security audits, before production deployments, or as part of regular security reviews. It is particularly useful for web developers configuring server responses, security engineers evaluating application hardening, and DevOps teams setting up CDN or reverse proxy configurations. It complements automated scanners by providing clear, actionable recommendations.

Common use cases

Security teams use this tool to audit web application headers before penetration tests, verify that Content-Security-Policy is correctly configured after changes, ensure HSTS is properly set up with sufficient max-age, check that clickjacking protections (X-Frame-Options) are in place, and document header configurations for compliance requirements. Developers use it to quickly identify which security headers are missing from their server responses.

What “secure headers” actually buy you

Each header closes off a specific attack class. The analyzer scores presence and configuration, because a misconfigured header can score zero while looking present.

HeaderDefends againstThe configuration that matters
Content-Security-PolicyXSS, data injectionAvoid unsafe-inline/unsafe-eval; prefer nonces or hashes
Strict-Transport-SecurityProtocol downgrade, cookie theftLong max-age, includeSubDomains, careful preload
X-Content-Type-OptionsMIME sniffingExactly nosniff
X-Frame-Options / frame-ancestorsClickjackingDENY or SAMEORIGIN (CSP frame-ancestors supersedes it)
Referrer-PolicyReferer leakagestrict-origin-when-cross-origin is a sane default
Permissions-PolicyUnwanted camera/geo/USB accessDeny features you don’t use

CSP: nonce vs hash vs the unsafe-inline shortcut

A Content-Security-Policy is only as strong as its weakest source. The three ways to allow inline scripts, from worst to best:

  • unsafe-inline — allows any inline script, which defeats the entire point of CSP. It’s the most common reason a site has a CSP header but no real XSS protection.
  • Hashes — you compute the SHA-256 of each known inline script and list it. Great for static pages; brittle if a script changes.
  • Nonces — the server emits a fresh random nonce-... per request and tags trusted <script nonce="..."> tags with it. An injected script has no valid nonce and won’t run. This is the production-grade answer for dynamic apps.

If your CSP contains unsafe-inline next to a nonce, note that modern browsers ignore unsafe-inline when a nonce or hash is present — a deliberate fallback so older browsers degrade gracefully without weakening newer ones.

The modern headers most audits forget

Beyond the classic five, three newer headers harden cross-origin isolation:

  • Cross-Origin-Opener-Policy (COOP)same-origin severs the window reference between your page and cross-origin popups, blunting a class of side-channel and tab-napping attacks.
  • Cross-Origin-Resource-Policy (CORP) — controls who can embed your resources, mitigating Spectre-style cross-origin reads.
  • Cross-Origin-Embedder-Policy (COEP) — required, together with COOP, to unlock SharedArrayBuffer and high-resolution timers.

You don’t need all of them everywhere, but a perfect classic-header score with none of these is a 2018-grade configuration, not a 2026 one.

Where to grab the headers to paste here

The fastest source is DevTools: open the Network tab, reload, click the document request, and read the Response Headers pane. From a terminal, curl -sSI https://example.com prints them directly. Paste the block in — status line included or not, the parser handles both — and read the recommendations against the tables above.

How helpful was this tool?

Click to rate

Advertisement

Key Concepts

Essential terms and definitions related to HTTP Header Analyzer.

Content-Security-Policy (CSP)

An HTTP response header that controls which resources (scripts, styles, images, fonts, etc.) the browser is allowed to load for a page. CSP is the primary defense against Cross-Site Scripting (XSS) attacks by preventing execution of unauthorized scripts. A well-configured CSP significantly reduces the attack surface of a web application.

HSTS (HTTP Strict Transport Security)

A security header (Strict-Transport-Security) that tells browsers to always connect to the site using HTTPS, even if the user types http://. It prevents protocol downgrade attacks and cookie hijacking. The max-age directive specifies how long the browser should remember to enforce HTTPS.

X-Frame-Options

An HTTP header that controls whether a page can be embedded in an iframe. Values are DENY (never allow framing), SAMEORIGIN (allow only from the same origin), or ALLOW-FROM uri (allow from a specific origin). This header prevents clickjacking attacks where a malicious site embeds your page in a hidden frame to trick users into clicking.

Frequently Asked Questions

How do I get the HTTP headers to analyze?

You can get HTTP headers using browser DevTools (Network tab → click request → Headers), cURL (curl -I https://example.com), or any HTTP client. Copy the response headers and paste them into this tool for analysis.

What security headers should every website have?

At minimum: Content-Security-Policy (prevents XSS), Strict-Transport-Security (enforces HTTPS), X-Content-Type-Options: nosniff (prevents MIME sniffing), X-Frame-Options (prevents clickjacking), and Referrer-Policy (controls referrer information). The analyzer checks for all of these and provides specific recommendations.

What does a security score of 100% mean?

A score of 100% means all recommended security headers are present and properly configured. However, security is not binary — the headers are one layer of defense. A high score indicates good header hygiene, but comprehensive security also requires proper backend validation, authentication, and other measures.

Can this tool fetch headers from a live URL?

This tool analyzes headers you paste into it — it does not make HTTP requests to external URLs. This design ensures your analysis is completely private and works without CORS restrictions.

Should I submit my domain to the HSTS preload list?

Only when you are certain every subdomain will serve HTTPS forever. Preloading hard-codes your domain into browsers with 'includeSubDomains', so any subdomain still on plain HTTP (an old staging box, an internal tool) becomes unreachable — and removal from the preload list takes weeks to months to propagate. The safe path: serve HSTS with a long max-age and includeSubDomains for a while first, confirm nothing breaks, then add the 'preload' directive and submit. Treat preload as a one-way door.

Which response headers reveal my tech stack to attackers?

Server (e.g. 'nginx/1.18.0'), X-Powered-By ('PHP/8.1', 'Express'), X-AspNet-Version, and X-Generator all advertise software and versions, letting an attacker match you against a CVE list in seconds. None of them serve any purpose for legitimate clients. Strip or blank them at the web-server or framework layer — in Express it's app.disable('x-powered-by'); in nginx, server_tokens off plus a header-clearing module. Quiet servers are harder to target.

Troubleshooting & Technical Tips

Common errors developers encounter and how to resolve them.

Headers not parsed correctly

Ensure headers are in the standard HTTP format: "Header-Name: value" with one header per line. Remove any HTTP status lines (like "HTTP/1.1 200 OK") before the headers, or include them — the parser handles both formats.

Low security score despite having security headers

The analyzer checks not just for header presence but also for proper configuration. For example, a Content-Security-Policy with "unsafe-inline" or "unsafe-eval" directives reduces the score because these weaken CSP protection. Check the specific recommendations for each header.

Unknown or custom headers not recognized

The analyzer focuses on standard security and common HTTP headers. Custom application headers (like X-App-Version) are displayed but not scored. This is expected behavior — only headers with security implications affect the score.

Related Guides

In-depth articles covering the concepts behind HTTP Header Analyzer.

Advertisement

Related Tools