HTTP Security Headers: A Practical Starting Set

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-Policy limits script, style and framing sources.
• X-Content-Type-Options: nosniff prevents MIME guessing.
• Referrer-Policy controls referral data.
• Strict-Transport-Security enforces HTTPS after careful deployment.
• CSP frame-ancestors controls 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.