HTTP security headers let a server place limits on browser behavior. They complement secure application code; they do not repair unsafe authorization or unvalidated input.
A useful baseline
Content-Security-Policylimits script, style and framing sources.X-Content-Type-Options: nosniffprevents MIME guessing.Referrer-Policycontrols referral data.Strict-Transport-Securityenforces HTTPS after careful deployment.- CSP
frame-ancestorscontrols who may embed the page.
Roll out with evidence
Inventory required third parties, test on staging and use CSP report-only mode before enforcement. Check login, checkout, embeds and mobile layouts.
Avoid header collecting
Every directive needs a purpose. Conflicting or obsolete headers can create false confidence. Validate actual responses at the CDN and origin because intermediaries may alter them.
Check more than the homepage
Error responses, downloads, API endpoints and redirects can pass through different infrastructure and lose headers. Test representative routes from outside the origin network.
Ownership matters
Document whether the application, web server or CDN sets each header. Multiple layers silently overwriting one another makes future changes risky. Keep one authoritative configuration and test it in deployment.
Deploy headers as tested controls, not copied snippets
Start with an inventory of pages, frames, scripts and cross-origin dependencies. Add one control in a staging environment, inspect browser reports and verify login, checkout, downloads and error pages. A strict header that breaks authentication is not “more secure” in practice.
Common responsibilities
HSTS belongs on consistent HTTPS delivery; Content-Security-Policy constrains resource execution; X-Content-Type-Options reduces MIME confusion; Referrer-Policy controls URL information sent elsewhere; Permissions-Policy limits selected browser features. Frame protection should reflect whether trusted embedding is genuinely needed.
Set each header in one authoritative layer, application, web server or CDN, and test externally. Duplicate or conflicting values can produce behavior nobody intended. Recheck after infrastructure changes, because redirects and generated error pages often bypass the normal configuration.
Keep a small automated test that requests representative HTML, API, download and error routes and asserts the intended values. That turns a one-time scanner result into a deployment requirement and catches a CDN rule or server migration that silently removes protection.
Choose headers from the risk, not a checklist
Security headers shape browser behavior, but they do not repair unsafe application code. Start with an inventory of scripts, frames, forms, downloads and cross-origin dependencies. Then add controls that match those behaviors. A copied header bundle can quietly break login, payments or embedded tools.
Begin with a Content Security Policy in report-only mode, clickjacking protection through frame-ancestors, a deliberate Referrer-Policy and X-Content-Type-Options: nosniff. Add HSTS only after every required subdomain works correctly over HTTPS.
Verify the response that visitors receive
Inspect the final public response at the CDN or reverse proxy, not only the application server. Redirects, cached pages and error responses can carry a different header set. Browser developer tools and an automated integration test should confirm both presence and expected values.
Document the owner and reason for every policy. When a vendor adds a new script, update the narrowest directive instead of allowing an entire scheme or unsafe inline execution. Review reports for real violations, remove stale allowances and retest important journeys after each change.