Security Headers

The full set, and what each one stops

X-XSS-Protection is worth calling out. The browser feature is gone, the header does nothing useful, and its legacy filter mode introduced vulnerabilities of its own. Do not add it.

HSTS

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Rules that bite:

- HSTS is ignored over plain HTTP, so it must be sent on the HTTPS response. - Roll out with a short max-age (600), verify, then raise it. A long max-age on a host that later needs HTTP is very hard to undo, since only visiting browsers can be told to forget it. - preload is close to permanent. Every subdomain must serve valid HTTPS forever, including internal ones, before you submit. - max-age=0 is how you retract it, and only for clients that visit again.

Content-Security-Policy

The highest-value and highest-effort header. Each directive whitelists sources for one kind of resource.

A strict, practical policy:

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0mPerRequest' 'strict-dynamic' https: 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self';
  font-src 'self';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none';
  form-action 'self';
  upgrade-insecure-requests

<script nonce="r4nd0mPerRequest">/* allowed by the nonce */</script>

The 'unsafe-inline' and https: entries alongside a nonce are deliberate fallbacks for old browsers, which ignore 'strict-dynamic' and nonces. Modern browsers see the nonce and ignore both. The nonce must be cryptographically random and regenerated per response, since a static nonce is no better than 'unsafe-inline'.

Deploy in report-only mode first, collect violations, then enforce:

Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/_csp"

Framing, referrers, and permissions

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

X-Frame-Options takes DENY or SAMEORIGIN only. The old ALLOW-FROM was never widely supported, so use CSP frame-ancestors when you need an allowlist, and send both headers for older browsers.

Permissions-Policy: camera=(), microphone=(), geolocation=(),
  payment=(), usb=(), fullscreen=(self)

() denies a feature everywhere, (self) allows it on your own origin, and (self "https://embed.example.com") extends it to a named origin. Denying what you do not use costs nothing and removes whole permission-prompt attack surfaces.

Cross-origin isolation

The COOP and COEP pair are what unlock SharedArrayBuffer and high-resolution timers, by proving no cross-origin content shares your process.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

Turning on COEP: require-corp will break third-party embeds that do not send Cross-Origin-Resource-Policy: cross-origin, so audit before enabling. Check self.crossOriginIsolated in the console to confirm it took effect.

Auditing what you actually serve

curl -sI https://example.com | grep -iE \
 'strict-transport|content-security|x-content-type|x-frame|referrer-policy|\
permissions-policy|cross-origin|server|x-powered-by'

# see everything, in order, following redirects
curl -sSL -D - -o /dev/null https://example.com

# confirm the redirect chain reaches HTTPS before HSTS is expected to apply
curl -sSIL http://example.com | grep -iE '^HTTP|^location|strict-transport'

Two closing points. These headers are defense in depth, not a substitute for output encoding, parameterized queries, and server-side authorization. And a header only protects the responses that carry it, so set them centrally at the proxy or framework layer rather than per route, where one omission becomes the hole.