Security Headers

Security headers are HTTP response fields that tell a supporting user agent to apply a security policy to a response or browsing context. Examples include Content Security Policy for resource and script restrictions, Strict-Transport-Security for future HTTPS-only connections, `X-Content-Type-Options: nosniff` for declared MIME-type handling, frame controls such as CSP `frame-ancestors` or the older `X-Frame-Options`, and policies for referrer data, browser features, and cross-origin isolation.

Why it matters: Select policies from the application's threats, content sources, embedded contexts, browser support, and deployment architecture rather than copying a universal header set. Inventory required behavior, configure headers at the layer that owns the final response, and check documents, APIs, errors, redirects, and cached or CDN-served variants. Roll out complex policies such as CSP in report-only mode, review violations, tighten deliberately, and test real sign-in, checkout, payment, media, analytics, and embedded journeys. Detect duplicate, conflicting, empty, obsolete, or incorrectly scoped values; treat HSTS and cross-origin isolation as changes with operational prerequisites and rollback consequences. Headers are defence in depth: they can reduce exposure or impact but do not replace secure coding, output encoding, dependency management, authentication, authorization, TLS, or application testing.