Security headers: what each one prevents

Security headers are instructions a site gives the browser about what it is allowed to do with the page. None of them fix a vulnerable application, but several of them stop a whole class of attack from being exploitable. The Web facet lists which ones a site sends.

In order of value

1. Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains. After the first visit the browser refuses to use plain HTTP for the site. Add preload only when every subdomain works over HTTPS and you have submitted the domain to the preload list.
2. Content-Security-Policy (CSP): controls where scripts, styles, images and frames may load from. The single most effective defence against cross-site scripting, and the hardest to get right. Start with Content-Security-Policy-Report-Only and a reporting endpoint.
3. X-Content-Type-Options: nosniff: stops the browser guessing a content type, which prevents a few injection tricks. No downside.
4. X-Frame-Options: DENY or the CSP frame-ancestors directive: stops your pages being embedded in someone else's frame for click-jacking.
5. Referrer-Policy: strict-origin-when-cross-origin: stops full URLs (which may contain tokens) leaking to other sites.
6. Permissions-Policy: switches off browser features the site does not use (camera, geolocation, payment).
7. Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy: isolation for sites that handle sensitive data.

Headers you can drop

X-XSS-Protection is ignored by current browsers and can cause problems in old ones; remove it. Expect-CT is obsolete.

Where to set them

At the web server or CDN, once, for every response. Apache uses Header always set, nginx add_header … always, and most CDNs have a headers rule. Check the result on the Web facet after deploying.