Security headers are the cheapest hardening you will ever ship: a few lines of configuration that enlist every visitor’s browser in defending your site. The edge is the right place to set them — one rule covers every response from every origin, including the legacy app nobody wants to touch. Here is the baseline, the values that fit most sites, and the two headers that punish copy-paste without thought.
Why the edge is the right place
Origin-set headers depend on every application, microservice and error page agreeing to send them — and the 500 page generated by a crashing backend is exactly the response that forgets. An edge rule (Cloudflare response-header transforms, CloudFront response headers policies, Akamai and Fastly header operations, or a rules engine on any mid-market CDN) applies uniformly: static assets, dynamic pages, errors, redirects. It also survives replatforming, which is why the edge copy should be the authoritative one even when origins send their own. The one discipline the edge placement demands is deduplication, covered in section five.
The baseline five, with values
Five headers cover most of the win for a typical site. Strict-Transport-Security forces HTTPS on returning visitors (details next section). X-Content-Type-Options: nosniff stops browsers second-guessing content types, closing a class of upload-based attacks; it has no legitimate downside on a correctly configured site. Referrer-Policy: strict-origin-when-cross-origin — the modern browser default, worth pinning explicitly — sends your full URLs to your own pages but only the origin to third parties, keeping tokens and private paths out of other people’s logs. Content-Security-Policy: frame-ancestors 'self' is the modern anti-clickjacking control, superseding the legacy X-Frame-Options (keep both during transition if very old clients matter; browsers ignore the legacy header when the CSP directive is present). And Permissions-Policy switches off browser features you do not use — camera, microphone, geolocation — so an injected script cannot quietly turn them on. Set all five in one edge rule and you have passed most automated header audits already.
HSTS: the one-way door
HSTS deserves its own caution because it is a promise you cannot easily take back. Once a browser sees max-age=31536000, it refuses plain HTTP to your domain for a year — which is the point, and also why you stage it: start with a short max-age (a day), confirm every subdomain actually serves HTTPS, extend to the full year, and only add includeSubDomains once you are sure no forgotten internal hostname still runs plain HTTP, because the directive breaks them for every visitor who has seen your homepage. The preload token and the browser preload list are the final, near-irreversible step — removal takes months to propagate — so submit only when the estate is genuinely all-HTTPS forever. TLS configuration underneath is its own topic: see tuning TLS at the edge.
CSP: report first, enforce later
A full Content-Security-Policy — the allowlist of where scripts, styles and frames may load from — is the strongest header and the only one that can break your site badly, because real pages accumulate third-party tags nobody documented. Treat it like a WAF: deploy as Content-Security-Policy-Report-Only with a reporting endpoint, run it for a few weeks, and let the violation reports write your allowlist for you — every report is either a source to permit or a tag to remove. Only then switch to enforcement, ideally tightening toward nonce-based script policies if your templates can carry a per-response nonce (which, note, makes those responses uncacheable — a genuine edge trade-off; hash-based policies cache cleanly). If a full CSP is more than the team can maintain, ship frame-ancestors alone from section two and return later; a stalled report-only experiment protects nobody.
Deduplication, exceptions and verification
Two rules keep the edge deployment honest. First, decide the precedence: if origins also send security headers, configure the edge to overwrite rather than append — duplicate or conflicting values are at best undefined behaviour and at worst a bypass (two different CSPs make browsers enforce the intersection, which may not be what either author intended). Second, scope exceptions narrowly: the embeddable widget that partners iframe needs its own path-level policy loosening frame-ancestors, not a site-wide retreat. Then verify from outside: curl the homepage, an asset, a 404 and an API route, and confirm the set is present and single on each; add the check to your synthetic monitors so a config regression pages someone. The full pre-launch context lives in the CDN security baseline.