UseToolSuite UseToolSuite

HTTP Header Analyzer

Paste HTTP response headers and get a weighted security grade, not a flat percentage: CSP and HSTS analysed directive by directive, information-disclosure headers flagged, and every Set-Cookie audited for Secure, HttpOnly and SameSite.

Paste HTTP headers and click Analyze to see results.

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.

HTTP Header Analyzer Powered by UseToolSuite — free browser tools

Last updated Built and maintained by Necmeddin Cunedioglu How tools are tested

How helpful was this tool?

Click to rate

Key Concepts

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.

Why does this tool say my X-XSS-Protection header is a problem?

Because it is. The header controls a legacy browser XSS filter that every current browser has removed, and the filter itself was shown to introduce vulnerabilities it was meant to prevent — which is why the recommended configuration is X-XSS-Protection: 0, or simply not sending it. Scanners that award points for having the header push you towards the harmful value. Here, absent and 0 both pass, and "1; mode=block" is flagged.

Why is the score weighted instead of a straight percentage?

Because a missing Content-Security-Policy and a missing Permissions-Policy are not the same problem. Averaging every header equally lets a site skip the two that matter and still score well by setting four that barely do. CSP carries 30 points, HSTS 25, X-Content-Type-Options and X-Frame-Options 15 each, and the rest a handful — and headers that leak a software version subtract from the total.

Does it handle headers sent more than once, like Set-Cookie?

Yes, and this matters more than it sounds. A response commonly sets several cookies, and a tool that stores headers in a plain key-value map keeps only the last one — so it silently analyses a response you did not send. Every value is kept, each cookie is audited separately for Secure, HttpOnly and SameSite, and a non-cookie header sent twice is flagged because that is usually a misconfiguration.

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

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

REST vs WebSockets: When to Use Each

REST vs WebSockets: request/response vs persistent full-duplex connections, polling vs push, latency and scaling trade-offs, and which fits real-time.

HTTP Security Headers: The Complete Checklist for Your Web App

An engineering guide to HTTP security headers: Content-Security-Policy, HSTS, and X-Frame-Options — and how they stop XSS, clickjacking, and MIME sniffing.

DNS Records Explained: What Every Developer Should Know

A practical guide to DNS records: A and AAAA resolution, the CNAME apex constraint, SPF/DKIM/DMARC email authentication, TTL strategy, and DNSSEC.

cURL for Developers: The Commands You'll Use Every Day

An engineering guide to cURL: OAuth authentication, multipart binary uploads, TLS handshake debugging, latency profiling, and HTTP header patterns.

Related Tools

SSL Certificate Checker

Network & API Tools

DNS Lookup

Network & API Tools

cURL to Code Converter

Network & API Tools

HTTP Status Codes Reference

Network & API Tools
Embed this tool on your site

Paste this snippet into any HTML page or blog post to embed a live, fully working copy of HTTP Header Analyzer. Free for any use.