HTTP Header Analyzer
Inspects deployed headers, redirect hops, cookies, isolation policy, and duplicate or conflicting fields.
Web SecuritySecurity Headers That Actually Change Risk
A long header list is not a security posture. The useful policies are the ones whose failure mode you understand, whose owner is known, and whose deployed value survives every CDN, proxy, redirect, and application release between source control and the browser.
Start with the response the browser receives
Security headers are unusually easy to configure and unusually easy to misread. An origin configuration can be perfectly reviewed while the public response is wrong: the CDN appends a second Content-Security-Policy, the load balancer strips Strict-Transport-Security from redirects, or an application route replaces the platform defaults. The browser does not enforce your Terraform, nginx template, or framework middleware. It enforces the final response, one status code and one hostname at a time.
Audit from the outside and retain raw evidence. The HTTP Header Analyzer groups security, cache, cookie, framing, and isolation findings, records a small redirect chain for public URLs, and explicitly surfaces duplicate or conflicting fields. Paste captured headers for internal services. Test HTML documents, APIs, errors, authentication callbacks, downloads, and redirects separately; a header present on the homepage says nothing about the response that actually handles sensitive state.
CSP is an application project, not a line of syntax
Content Security Policy has the highest ceiling and the worst rollout folklore. A copied policy containing default-src 'self' looks decisive until inline bootstraps, analytics, customer uploads, workers, frames, and third-party payment flows meet it. The usual reaction is to add 'unsafe-inline', broad wildcards, and entire CDN domains until the page works. That produces a decorative CSP: formally present, operationally incapable of stopping the script injection it was meant to contain.
Build CSP from an inventory of execution and data flows. Begin with Content-Security-Policy-Report-Only, collect violations with route and release context, then remove accidental dependencies rather than merely allowlisting them. Prefer nonces or hashes for intentional inline code, keep object-src 'none' unless an old application proves otherwise, set base-uri and frame-ancestors explicitly, and treat script-src as code review. Report-only is a migration instrument, not an end state; enforce a useful baseline, then tighten it in measured releases. CSP changes belong beside application tests because the application owns what must execute.
HSTS is simple until you widen its blast radius
Strict-Transport-Security tells a browser that has already reached HTTPS to use HTTPS for future connections. A production site normally wants a substantial max-age, but rollout should be staged: start short, watch failures, then extend. includeSubDomains is not an aspirational badge. It is a promise that every current and future descendant — vendor portals, forgotten appliances, delegated zones, and temporary campaign hosts included — can serve valid HTTPS.
Preload goes further by shipping that promise inside browsers, closing the first-visit gap but making reversal slow and operationally painful. Only request it after a complete subdomain inventory, redirects are clean, certificate automation is proven, and the organization accepts the long removal tail. Validate the transport endpoint itself with the TLS Configuration Checker, which reports protocol support, certificate-name matching, ALPN, SNI behavior, HSTS evidence, and coarse weak-configuration findings. HSTS cannot rescue an expired certificate or a hostname that never had HTTPS.
Small controls still close real doors
X-Content-Type-Options: nosniff is unglamorous and broadly worth sending. It tells browsers not to reinterpret declared script and style types, turning correct Content-Type values into a security boundary rather than a suggestion. It does not repair wrong MIME types; deploy it with accurate response metadata and test downloads, legacy assets, and generated files. For framing, prefer CSP frame-ancestors; retain X-Frame-Options where older clients matter, but do not let two contradictory policies drift independently.
Cookies deserve the same precision. Secure prevents transmission over plaintext, HttpOnly withholds a cookie from script, and SameSite constrains cross-site sending. None is universally interchangeable with another. A session cookie generally needs all three, while an OAuth or federated-login callback may require carefully scoped SameSite=None; Secure. Keep Domain absent for host-only cookies where possible, make Path no broader than needed, and use the __Host- prefix for high-value host-bound cookies. Cookie flags reduce exposure; they do not make XSS harmless.
Isolation headers change the page's ecosystem
Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy can place a document in a cross-origin-isolated browsing context, protecting its window relationship and enabling capabilities such as SharedArrayBuffer. That is a meaningful boundary, not baseline garnish. COOP: same-origin can disrupt popup-based authentication and payment flows; COEP: require-corp blocks cross-origin resources unless they participate through CORS or Cross-Origin-Resource-Policy. A single uncooperative font, image, worker, or vendor script can break the page.
Deploy isolation by route and dependency graph. Inventory every embedded origin, test opener and popup behavior, and confirm that resource owners can send the required CORS or CORP signals. COEP: credentialless can be useful where supported, but it changes credential handling and still deserves compatibility testing. If the application does not require cross-origin isolation, adding the headers for a scanner score buys little and creates a maintenance obligation. A policy with no consumer and no test is future breakage waiting for a release window.
Assign one writer and verify every path
Duplicate fields reveal missing ownership. Some headers combine across lines, some effectively select one value, and some become invalid or unexpectedly restrictive when intermediaries append them. Two CSP fields are both enforced, which means their intersection may break content even though each layer's policy looks reasonable. Multiple HSTS values, contradictory framing directives, or repeated cookie mutations are signals that the CDN and origin are independently governing the same response.
Choose one authoritative layer per policy, document exceptions, and make downstream layers replace rather than append when replacement is intentional. Test the canonical URL and every redirecting hostname with the Redirect / Canonical / Indexability Checker to expose redirect and final-URL behavior, then inspect headers on each response. Keep regression samples in CI, but retain a scheduled public probe: configuration correctness before deployment and effective behavior after deployment are different facts. The second is the one users receive.