How To Fix Security Headers

Start with the headers that are unlikely to surprise you: X-Content-Type-Options, Referrer-Policy, and X-Frame-Options. They give the browser clearer rules without usually changing how a page loads.

After you add them, check the live site with the Security Headers Checker at /security-headers-checker. The response users see can be changed by your CDN, host, proxy, or framework.

A good first pass is: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and X-Frame-Options: DENY or SAMEORIGIN.

Strict-Transport-Security is useful, but do not rush it. Only send HSTS when HTTPS is working reliably for the host.

Start with a shorter max-age while you test. Use includeSubDomains and preload only when every important subdomain is ready for HTTPS.

Before using a long HSTS value, check the public certificate with /ssl-checker and make sure HTTP redirects cleanly to HTTPS with /redirect-checker.

Content-Security-Policy is the header most likely to break something if it is too strict too soon. It can block scripts, styles, images, fonts, frames, and API calls.

For an existing site, start with report-only mode. Build the policy from what the page actually uses, and avoid broad allowlists when a smaller rule will do.

For static sites, your hosting provider or CDN is often the easiest place to add headers. For apps, middleware, route handlers, reverse proxy config, or platform header settings can all work.

Try to keep the rules in one obvious place. If both your app and CDN set the same header, the final response can be different from what your code suggests.

After changing headers, scan the production URL, not only localhost or staging. Redirects matter because the final host may be where the real headers are added.

When you need help from a teammate or hosting support, share the raw headers or JSON output. It removes guesswork and shows exactly what the server returned.