Security Headers Checker
Semantically analyzes CSP, HSTS, and other security headers -- including their actual directive values, not just presence -- plus GET vs HEAD parity and where HTTPS protection begins across a redirect chain.
Based on: RFC 9110 — HTTP Semantics
About this validation
Semantically parses Content-Security-Policy, Strict-Transport-Security, and other security-relevant response headers, compares GET against HEAD, and inspects redirect-chain behavior. Findings reflect actual directive values, not header presence alone, and never claim a site is insecure solely because a recommended header is absent.
- Protocol / standard:
- Rules reviewed:
- Sep 6, 2026
SEOTechTests methodology: Data source: a live HTTP response-header fetch performed by SEOTechTests, comparing GET and HEAD and parsing actual directive values (not just header presence). Standard: RFC 9110 defines the HTTP semantics these headers operate within; individual headers like CSP and HSTS have their own governing specifications, checked in more depth by this site's dedicated CSP and Mixed Content checkers.
Standards and vendor-documented behavior can change. This reflects the source as last reviewed above, not a permanent guarantee.
What This Test Checks
Parses Content-Security-Policy directives for risky patterns (unsafe-inline, unsafe-eval, wildcard sources) and missing hardening directives (object-src, frame-ancestors, base-uri); validates Strict-Transport-Security's max-age, includeSubDomains, and preload eligibility; checks Referrer-Policy and Permissions-Policy values; explains COOP/COEP/CORP combinations; flags headers that reveal server implementation details (Server, X-Powered-By); compares GET against HEAD; and walks the redirect chain to show exactly where HTTPS (and therefore HSTS/CSP enforcement) begins.
FAQ
Is a missing recommended header always a problem?
No. Most findings here are labeled Recommendation or Informational specifically because a header's absence alone is rarely a real vulnerability. Only concretely risky configurations (an unsafe CSP directive, a malformed HSTS value, a mismatch between GET and HEAD) are flagged as Warning, High, or Critical.
Why compare GET and HEAD?
Some monitoring tools, caches, and crawlers use HEAD to check a page cheaply and assume its headers match what GET would return. When the security headers actually differ, those tools see an inaccurate picture.
Why show the redirect chain?
HSTS and CSP can only take effect once a connection is actually HTTPS -- a plain HTTP response can't enforce either, no matter what headers it sends. Showing the chain makes clear exactly where that protection begins.
Does this give a numeric security score?
Only a rough summary count by severity, never a single score. A simplistic points system (header present = points) doesn't reflect how much any one header actually matters in context, so findings are the primary output here.