Security headers: what your website configuration should include

Security headers tell browsers how to handle transport, framing, content types, referrers and script execution. Configure them at the edge or web server, test in report-only mode where possible, and verify actual response headers on every important URL.

Last updated 2026-08-26

Which security headers matter most?

Start with Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and frame protection. Each addresses a different browser risk; headers do not replace secure application code or correct cookie settings.

Permissions-Policy can reduce access to camera, microphone and geolocation. Configure only the capabilities the site needs.

• HSTS requires HTTPS after a browser has seen the policy; confirm every subdomain supports HTTPS before preload.
• CSP restricts scripts, styles, frames, images and connections; begin with report-only mode.
• X-Content-Type-Options prevents MIME sniffing when assets have correct content types.
• Referrer-Policy limits URL information sent to other origins.
• CSP frame-ancestors provides modern, granular frame protection.

How should you roll out a Content Security Policy?

Inventory every script, stylesheet, font, image, frame and connection, including analytics and payment providers. Begin in report-only mode, review violations, remove unexpected sources, and enforce the policy in stages.

Avoid solving every violation with a wildcard or unsafe-inline. Nonces or hashes are safer for scripts that genuinely need inline execution.

How do you verify a security-header change?

Verify the final response after redirects from representative URLs and user agents. Then load the site in a clean browser session and test forms, checkout, embeds, analytics consent and authenticated flows.

CDN rules, redirects, error pages and static assets can each return a different policy, so check more than the homepage.