Zap.Tools
By Updated

HTTP Header Checker

Inspect every response header from any URL: security (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, cookie flags), performance (Cache-Control, ETag, compression), and the full redirect chain.

Interactive tool

URL to inspect

The URL is fetched server-side via our SSRF-safe backend. Non-public addresses are rejected and the URL is not logged.

What is the HTTP Header Checker?

A free HTTP response-header inspector with three lenses: security (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP), performance (Cache-Control, ETag, compression), and the full redirect chain. Each finding includes a copy-pasteable remediation snippet.

How to Use the Header Checker

  1. 1Paste any http(s):// URL
  2. 2Click Check headers: a server-side request is sent through our SSRF-safe backend
  3. 3Read the Summary card: status, final URL after redirects, redirect chain
  4. 4Filter findings by category: Security, Performance, Caching, CORS
  5. 5Inspect cookie attributes (Secure, HttpOnly, SameSite) for every Set-Cookie
  6. 6Copy any remediation snippet directly into your server config
What you get

Key features

Comprehensive security audit

HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP: each with a pass/warn/fail verdict and a remediation snippet

Cookie attribute analysis

Every Set-Cookie is parsed for Secure, HttpOnly, SameSite, Path, Domain, Expires, and Max-Age, with explicit warnings for missing flags

Performance & caching checks

Cache-Control, ETag/Last-Modified, Content-Encoding (gzip/br/zstd): flags missing compression and missing validators

Full redirect chain

Up to 5 hops captured with status code at each hop: catches infinite redirect loops and accidental http→https→http→https chains

CORS configuration sanity

Detects the Allow-Origin=* with Allow-Credentials=true bug that browsers silently reject

Stack-fingerprint detection

Flags Server and X-Powered-By headers that leak framework or runtime to attackers

Copy-pasteable remediation

Every flagged check includes a one-liner you can drop into Nginx, Cloudflare Workers, Vercel headers config, or your framework middleware

Why Audit Response Headers?

A page can ship working HTML and still leak sessions, allow clickjacking, or downgrade to HTTP: all of which are invisible to browser DevTools without specifically going looking. Most of these issues are fixed by adding a single header line in your server config or framework middleware. The hard part is knowing which ones are missing. This tool lists exactly that, with the ready-to-paste fix beside each finding.

Common use cases

  • Pre-launch security review of a new domain
  • Comparing headers across staging vs production environments
  • Diagnosing why a third-party browser refuses your CORS request
  • Verifying CDN-level header rewrites are landing as expected
  • Catching accidentally re-introduced X-Powered-By: Express
  • Validating that SameSite=None cookies have Secure (Chrome silently drops otherwise)
  • Confirming HSTS preload eligibility (max-age ≥ 1 year, includeSubDomains, preload)

Why GET instead of HEAD?

Many origins block or mishandle HEAD requests, returning 405, missing headers, or broken redirects. The proxy uses GET with abort-after-headers (the same trick curl -I -L falls back to). For purpose: headers requests, the body is discarded the moment the headers arrive.

How is this different from securityheaders.com?

Same goals, different scope. This tool is a one-shot ad-hoc audit you run from the Zap.Tools dashboard alongside your other SEO and dev tools. It does not maintain a public history, score, or grade: that is a deliberate choice to keep the focus on the diff between your current and ideal config.

What "Cross-origin isolation" means

COOP=same-origin + COEP=require-corp together enable cross-origin isolation, which unlocks SharedArrayBuffer, performance.now() with full precision, and other powerful APIs gated behind Spectre mitigations. If your app uses WebAssembly threading or fine-grained timers, you need this combo.

Common pitfalls this tool catches

  • HSTS max-age below 1 year (preload-list ineligible)
  • CSP with unsafe-inline (defeats most XSS protection)
  • X-Frame-Options missing without CSP frame-ancestors fallback
  • Set-Cookie without Secure on HTTPS endpoints
  • SameSite=None without Secure (Chrome rejects)
  • Allow-Origin=* with Allow-Credentials=true
  • Server: nginx/x.y.z leaks (or X-Powered-By: PHP/x.y.z)
  • Missing Content-Encoding entirely (uncompressed JSON APIs)
  • Long redirect chains burning crawl budget
Pro tips

Tips & best practices

Set headers at the edge, not the app

Move HSTS/CSP/X-Frame-Options/etc. to Nginx, Cloudflare, or Vercel's headers config. App-level middleware can be bypassed by direct CDN cache hits, especially for static assets.

Start CSP in Report-Only

A bad CSP breaks the page silently. Ship Content-Security-Policy-Report-Only first, watch the report endpoint for a week, fix the violations, then flip to enforcing.

HSTS preload is one-way

Once a domain hits the HSTS preload list, browsers refuse HTTP for it forever. Test with includeSubDomains and preload set on staging first, then submit to hstspreload.org.

Strip stack-leak headers at the proxy

Server and X-Powered-By are minor info leaks but trivially fixed: add a single proxy_hide_header line in Nginx or remove_proxy_response_header in Caddy.

Verify cookies on every change

Cookie defaults vary across frameworks and changes between major versions. Re-run this check after any auth or session library upgrade.

Built for trust

Privacy & security

The URL is sent to our SSRF-safe backend, which applies non-public-address blocking, a request timeout, and discards the response body the moment the headers arrive. Only the URL leaves your browser, and the URL is not logged.

Related tools

Frequently Asked Questions

Why does this tool need a server-side fetch?

Browsers cannot read response headers from arbitrary cross-origin URLs (the same-origin policy blocks it). To inspect the headers a browser would receive but cannot expose to JavaScript, the request must run on the server. We use the same SSRF-safe backend that powers the rest of the SEO batch.

Does it use HEAD or GET?

GET, with the response body discarded as soon as the headers arrive. Many origins block HEAD or return inconsistent headers for it; using GET matches what curl -I -L falls back to and what real browsers actually receive.

Which security headers are checked?

HSTS (Strict-Transport-Security), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (with frame-ancestors fallback), Referrer-Policy, Permissions-Policy, COOP, COEP, CORP, plus stack fingerprinting (Server, X-Powered-By) and CORS sanity (Allow-Origin=* with Allow-Credentials=true is invalid).

Are private IPs blocked?

Yes. Our backend refuses any URL that resolves to a non-public address: loopback, private, link-local, or otherwise internal, and a request timeout is enforced.

What is the difference between Permissions-Policy and Feature-Policy?

Feature-Policy is the legacy name; Permissions-Policy is the standard that replaced it. Modern browsers read Permissions-Policy. If you only have Feature-Policy set, this tool flags it as a warning so you migrate.

Why does my CORS preflight fail when I have Allow-Origin=*?

Browsers reject Allow-Origin=* combined with Allow-Credentials=true. For credentialed requests, the Allow-Origin must echo the specific request origin. This is one of the most common silent CORS failures, and the tool flags it explicitly.