Security headers

Security headers are HTTP response headers that ask the browser to behave more strictly on your site. The set worth knowing: Strict-Transport-Security (never speak plain HTTP to this domain again), Content-Security-Policy (only load scripts and resources from this allowlist, which is the one that actually blunts XSS), X-Content-Type-Options: nosniff (do not guess file types), Referrer-Policy (stop leaking full URLs to other sites), Permissions-Policy (nobody here needs the camera), and the cross-origin trio COOP, COEP, and CORP for isolating your page from other origins. X-Frame-Options is the old clickjacking defense, now superseded by CSP frame-ancestors, and X-XSS-Protection is dead: modern browsers ignore it, so delete it.

They cost nothing to add, which is why they are a standard hardening pass. Set them once at the edge (CDN, reverse proxy) or in framework middleware so every route inherits them, rather than sprinkling them per handler. Then check the result with a scanner and with your browser console, not with your intentions.

Gotchas. CSP is the only one that takes real work: turn it on with Content-Security-Policy-Report-Only first, collect violations for a week, and expect inline scripts, analytics snippets, and embedded iframes to break, which is why nonces or hashes beat 'unsafe-inline'. HSTS is close to irreversible once browsers cache it, and the preload list is worse, so do not ship includeSubDomains until every subdomain really does have a certificate. And an A+ grade from a header scanner measures your headers, not your app: it says nothing about your authorization bugs.