Security Header Checker
Paste HTTP response headers to validate security header presence, correct values, and flag missing or misconfigured headers.
Calculations run locally in your browserSecurity Header Checker
The Security Header Checker validates HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, COOP, COEP, Referrer-Policy, and Permissions-Policy header correctness.
• Audit security headers before a penetration test engagement
• Check whether HSTS includeSubDomains is set before submitting to the preload list
• Validate COOP and COEP headers before enabling SharedArrayBuffer
• Identify deprecated security headers that should be replaced with modern equivalents
How Security Header Checker fits into production review
Security Header Checker belongs in the edge-hardening review for browser-exposed routes. The meaningful headers are policy controls: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options or frame-ancestors, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy, and reporting endpoints. Each header changes browser behavior; none should be treated as decorative compliance copy.
A production review needs to tie the header to a route class. The homepage, authentication callback, static asset path, embedded widget, API JSON route, documentation page, and third-party checkout return page may need different policies. A strict CSP on a marketing page is not proof that an embedded widget is safe. HSTS on the apex domain does not automatically mean every subdomain is ready for preload. Frame controls that protect the app shell may break legitimate embedding surfaces if applied without route awareness.
The result should feed deployment governance. Capture whether the policy comes from application code, CDN rules, reverse proxy config, framework middleware, or a Worker response branch. That source matters when a later release changes one route but not another. For CSP, record whether the policy is enforcing or report-only, whether nonces or hashes are used, and which third-party origins are intentionally allowed.
When this result can be misleading
A green header list can hide a weak policy. Content-Security-Policy that allows unsafe-inline, broad wildcards, data: scripts, or every analytics domain may pass a presence check while offering little protection. Permissions-Policy can list controls that no browser enforces consistently. Referrer-Policy can be present but still leak path data if set too loosely for sensitive flows. Presence is only the first layer.
Route coverage is the bigger trap. Testing one URL through a browser does not prove the same headers are emitted by error pages, redirects, static files, API responses, regional domains, preview deployments, or cached CDN variants. Some frameworks add headers only after successful rendering. Others lose them when a 404, 500, image, or rewrite path is served by a different component. Check representative route families, not one lucky response.
Header inheritance can also mislead. A CDN may add a header that the origin never sees, or an origin may emit a header that the edge strips. Browser behavior follows the final response after redirects and caching, so the review should include the effective response from the public URL. Close the issue only when the policy owner and route owner both agree on the intended behavior.
Document the exact final URL, status code, redirect chain, and cache status used for the check. Header posture can differ between www and apex, localized routes, preview hosts, and error responses, so the evidence should name the route family that was actually tested externally.