What is the most important security header to implement first?

Start with Strict-Transport-Security (HSTS) because it requires the least configuration and provides immediate protection against SSL stripping attacks. Set a short max-age initially (300 seconds), verify your site works correctly over HTTPS, then increase to 63072000 seconds (2 years) with includeSubDomains. After that, implement X-Content-Type-Options (nosniff) and X-Frame-Options (DENY), which are single-value headers with no risk of breaking functionality. Deploy Content-Security-Policy last since it requires the most testing.

How do I deploy Content-Security-Policy without breaking my site?

Use the Content-Security-Policy-Report-Only header first. This evaluates your policy against all resources on the page and sends violation reports to your report-uri endpoint without actually blocking anything. Monitor the reports for a few weeks to identify all legitimate content sources, adjust your policy directives accordingly, then switch from Report-Only to the enforcing Content-Security-Policy header. This iterative approach prevents unexpected breakage.

Can I use both X-Frame-Options and CSP frame-ancestors at the same time?

Yes, and it is recommended for backward compatibility. CSP frame-ancestors supersedes X-Frame-Options in modern browsers that support CSP Level 2+. However, older browsers (like IE11) only understand X-Frame-Options. Setting both headers ensures clickjacking protection across all browser versions. If there is a conflict, browsers that support CSP will use frame-ancestors and ignore X-Frame-Options.

Why should I avoid using unsafe-inline and unsafe-eval in my CSP script-src directive?

The unsafe-inline keyword allows any inline script to execute, which means an attacker who injects HTML (via XSS) can run arbitrary JavaScript. The unsafe-eval keyword allows eval(), new Function(), and similar dynamic code execution, which attackers commonly exploit. Both keywords effectively negate CSP's XSS protection. Instead, use nonces (a unique random token per request added to both the CSP header and script tags) or hashes (SHA-256 hash of the inline script content) to allow specific inline scripts.

What happens if I set HSTS max-age too high and then need to revert to HTTP?

Browsers that have cached your HSTS policy will refuse to connect over HTTP until the max-age expires, effectively making your site unreachable for those users if HTTPS stops working. There is no server-side way to clear a client's HSTS cache. Users would need to manually clear their browser's HSTS settings. This is why gradual rollout is critical: start with max-age=300 (5 minutes), increase to 86400 (1 day), and only set the full 63072000 (2 years) after thorough verification.

API Security Headers: CSP, CORS, HSTS