Why security headers matter more than they seem
A site without security headers is like a house with a good lock but open windows. The server can be perfectly protected, but if it doesn't tell the browser how to behave when rendering your content, you open the door to XSS, clickjacking, MitM and other attacks. Correct HTTP headers close those windows at browser level.
The classic case is Strict-Transport-Security (HSTS). Without HSTS, a user typing "example.com" without https:// makes first request via HTTP. An attacker on public wifi can intercept that first request and serve malicious content even if your server redirects to HTTPS. HSTS tells the browser "for this domain, always HTTPS, never HTTP" from next visit. With preload activated, not even first visit goes via HTTP.
The other pillar is Content Security Policy (CSP). Even if an attacker manages to inject JavaScript on your page (XSS), strict CSP with default-src 'self' prevents that JS from loading external scripts, opening malicious iframes or exfiltrating data to unauthorized domains. Mozilla Observatory, SecurityHeaders.com and similar tools rate your site A+ only if you have strict CSP correctly configured.
Critical headers: minimum recommended set
For a modern web app, OWASP recommends at least these: Strict-Transport-Security with 1-year max-age + includeSubDomains + preload, Content-Security-Policy at least with default-src self, X-Content-Type-Options nosniff to prevent MIME sniffing, X-Frame-Options DENY or equivalent CSP frame-ancestors none for anti-clickjacking, and Referrer-Policy strict-origin-when-cross-origin to avoid leaking sensitive URLs.
The Permissions-Policy header (formerly Feature-Policy) controls which browser APIs your site can use: camera, microphone, geolocation. If your app doesn't use camera, declaring camera=() prevents an injected malicious script from activating camera even if user previously granted permission. It's defense in depth: even if CSP fails, Permissions-Policy blocks next step.
Cookies deserve special treatment. Every session cookie should have Secure (HTTPS only), HttpOnly (not accessible from JS), SameSite=Strict or Lax (anti-CSRF). The __Host- prefix in name forces Secure + Path=/ + no Domain, giving you the most secure possible cookie. Stripe, GitHub and Google use __Host- and __Secure- prefixes in production.
Common mistakes when configuring security headers
Mistake #1: activating HSTS preload before being ready. Once your domain enters the HSTS preload list (maintained by Chromium), exiting takes weeks or months. If you break HTTPS for any reason, the site becomes inaccessible for users with those browsers until removed from preload. Start with max-age=300 (5 min), increase to 86400 (1 day), then 31536000 (1 year), and only then add preload.
Mistake #2: too-permissive CSP. script-src 'self' 'unsafe-inline' 'unsafe-eval' * is basically "allow everything". If your CSP needs unsafe-inline because your app uses inline styles or HTML event handlers, improve the app before relaxing CSP. Google recommends using nonces or hashes instead of unsafe-inline. SecurityHeaders.com gives F if you use unsafe-inline even if rest is fine.
Mistake #3: conflicting or duplicate headers. If your app server sets X-Frame-Options DENY and your nginx sets X-Frame-Options SAMEORIGIN, browser may take either and break legitimate iframes. Audit the full chain: app server, reverse proxy, CDN. Cloudflare allows header override and silently overwrites what you set in nginx. Test with curl -I on final public endpoint.
Testing and monitoring security headers
Three tools to audit production headers: SecurityHeaders.com grades A+ to F based on present headers and values. Mozilla Observatory is stricter and adds TLS/SSH analysis. Hardenize.com is most complete, also evaluates CAA, DNSSEC and other DNS configurations. Aim for A+ on all three before declaring site "secure".
For CSP specifically, the strategy is Report-Only mode first. Start with Content-Security-Policy-Report-Only that reports violations to an endpoint but blocks nothing. That shows you which inline scripts, external resources and behaviors the proposed CSP breaks. After adjusting the app or making correct allow-list, switch to normal Content-Security-Policy which does block.
In CI/CD, add header tests with tools like helmet (Node), django-csp (Python) or secure-headers-rust. These middlewares apply secure defaults and allow controlled exceptions. Better prevent a bad deploy with lax headers than discover it on SecurityHeaders after a crawler indexed your insecure site for 3 days. Vercel, Netlify and Cloudflare Pages allow declaring headers in versioned config files.