Skip to content

Security Headers Analyzer

Paste response headers and get a graded audit of HSTS, CSP, frame options, cookies and more.

How it works

Security headers are the cheapest hardening in web engineering: a handful of response headers that disable whole attack classes — protocol downgrade, clickjacking, MIME sniffing, referrer leakage, feature abuse, weak cookies. The problem is remembering what good looks like: which headers must exist, what values are strong, and which headers should not exist at all. This analyzer answers all three from a paste of raw response headers.

Ten checks run: HSTS (with max-age, includeSubDomains and preload evaluation), Content-Security-Policy (including unsafe-inline/unsafe-eval warnings), X-Frame-Options with CSP frame-ancestors as an accepted modern alternative, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, cookie flags (Secure, HttpOnly, SameSite), and the two information-leak headers — Server and X-Powered-By — that should be absent.

Each check returns a status, a plain explanation of why the header matters, and the exact fix. The grade (A to F) counts passing checks, so the path to A is unambiguous: paste, fix the red items first, re-check after deploy.

Analysis happens entirely in your browser. Grab headers with curl -sI or the browser's network panel and paste — nothing is transmitted, which makes the tool safe for staging and internal hosts too.

Worked example

Paste a typical hardened-but-imperfect response: HSTS is strong, CSP has unsafe-inline, cookies miss flags, and PHP leaks its version.

HeaderStatusFix
strict-transport-security: max-age=31536000; includeSubDomains✅ okNothing — consider preload.
content-security-policy: ... 'unsafe-inline'🟠 warnReplace inline scripts with files or nonces.
set-cookie: session=abc; Path=/🟠 warnAdd Secure; HttpOnly; SameSite=Lax.
x-powered-by: PHP/8.1.2🟠 warnRemove the header entirely.
  1. Collect headers: curl -sI your site or copy them from the network panel.
  2. Paste and read: Each check shows status, why it matters and the exact fix.
  3. Fix red first: Missing HSTS and CSP beat every warning in priority.
  4. Re-check after deploy: The grade must move — verify, do not assume.

Score: 7/11 → grade C. Fixing the cookie flags and removing X-Powered-By lifts the same response to 9/11 without touching the application — the point of the exercise.

Common errors and edge cases

  • Headers on the error pages too. Security headers set only on 200s leave 404s and 500s unprotected. Apply them server-wide, at the edge if possible.
  • HSTS without includeSubDomains. Subdomains stay on HTTP. Include it — but audit subdomains first, because HSTS is sticky and hard to roll back.
  • frame-ancestors vs X-Frame-Options conflicts. Both are fine together (XFO for legacy, CSP for modern); mismatched values between them create confusing behavior.
  • Cookies set by third parties. The analyzer checks your Set-Cookie; embedded services set their own. SameSite=None requires Secure — and a real cross-site need.
  • Testing only production. Staging often lacks the edge rules. Paste staging headers too, or the gaps ship to prod with the next deploy.

Code equivalents

Grab the headers to paste, and the Nginx block that clears the most common misses in one move.

TaskCommand
Collectcurl -sI https://yourdomain.com — or copy from the browser network panel.
Nginx baselineadd_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; plus nosniff, frame options, referrer policy.
VerifyRe-paste after deploy — the grade should move before you close the ticket.

Frequently asked questions

Which security header matters most?

HSTS for anything user-facing over HTTPS, then a Content-Security-Policy without unsafe sources. Together they neutralize downgrade attacks and most XSS execution, the two highest-impact classes.

Is an A grade enough to be secure?

No. Headers are the cheap outer layer; they do not fix injection, authorization or logic bugs. Treat the grade as hygiene, not as a pentest.

Why does the analyzer flag Server and X-Powered-By?

They disclose software and exact versions, which shortens an attacker's vulnerability research to a lookup. Removing them is free and breaks nothing.

What cookie flags are required?

Secure (HTTPS only), HttpOnly (no JavaScript access) and SameSite (Lax or Strict for sessions). SameSite=None is only for genuine cross-site flows and requires Secure.

How do I test headers on staging or internal hosts?

Exactly as with production: curl -sI the staging URL and paste. Everything runs locally in your browser, so internal addresses never leave your machine.

Privacy note

All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.