Setting Security Headers in 2026: CSP, HSTS, COEP, and What Actually Matters

CSP is the most powerful and most-misconfigured security header. A correctly-configured CSP eliminates entire classes of XSS — including those introduced by future code changes you did not write. An incorrectly-configured CSP either breaks the site or, more commonly, is so loose it provides no protection at all.

The 2026 best-practice is strict-dynamic with per-request nonces. This means: every script you include in your HTML gets a nonce attribute matching a random value emitted in the CSP header, and the policy uses 'strict-dynamic' to let those scripts load anything they need transitively. The result is a single allowlist anchor (the nonce on your initial scripts) that propagates trust to dependencies without requiring you to enumerate every CDN.

The alternative — script-src 'self' https://cdn.example.com https://www.googletagmanager.com ... — is the legacy pattern. It works, but it requires maintaining an allowlist that grows every time a new third party is added, and it does not protect against XSS where attacker-controlled data appears in a pointing at an allowlisted domain.

The cost of strict-dynamic is that every inline script (and every dynamically-injected script) needs a nonce. Frameworks help here: Next.js has next/script with nonce support, SvelteKit has csp config in svelte.config.js, Astro has @astrojs/security middleware. Without framework help, you generate a nonce per request server-side and inject it into both the CSP header and every tag.

The standard rollout pattern is: deploy in report-only mode, monitor for 2-4 weeks, fix the violations, then enforce. The Content-Security-Policy-Report-Only header has identical semantics to Content-Security-Policy but only reports violations instead of blocking — perfect for staging the rollout.

Pair report-only with a report-uri (deprecated but widely supported) or report-to (the modern equivalent) directive. Browsers will POST violation reports to the configured endpoint as JSON. Run the endpoint as a small ingestion service (Postgres + a tiny API, or a managed reporting service like report-uri.com or Sentry's CSP reports).

Real CSP rollouts always surface surprises. Common ones: third-party iframes that inject scripts (analytics, chat widgets); developer-tools extensions that inject content scripts (these can be ignored — they are violations from the user's browser, not your code); A/B test scripts that inject inline styles; legacy code that uses eval() directly or via new Function().

Once the report-only run is clean for a week, switch to enforcement. Keep the report-uri active for ongoing monitoring — new violations from third-party services or new code paths are common, and silent breakage in production is expensive.

HSTS (HTTP Strict Transport Security, RFC 6797) tells browsers to only connect to your domain over HTTPS, never plain HTTP. Once a browser has seen the header once, it caches the policy for the configured max-age duration and refuses to make HTTP connections regardless of what links or redirects say.

The minimum useful HSTS header is Strict-Transport-Security: max-age=31536000; includeSubDomains. The max-age is one year in seconds. The includeSubDomains extends the policy to every subdomain — necessary for full protection but means you cannot have any HTTP-only subdomains (rare but worth checking before enabling).

For maximum protection, submit your domain to the HSTS preload list at hstspreload.org. Once accepted, every Chromium, Firefox, and Safari browser ships with your domain hard-coded as HTTPS-only. The submission requirements are strict: 2-year max-age, includeSubDomains, the preload directive, and HTTPS on every subdomain. Removal from the preload list takes 12+ months — submit only after careful verification.

Preload submission is the right answer for any domain that has been HTTPS-only for at least a few months. The asymmetric protection (any user who has never visited before is still vulnerable to a downgrade attack on first visit, until preload covers it) is the canonical reason to push for preload status.

These three are stable, well-supported, and nearly free to deploy. There is no good reason not to set them.

X-Content-Type-Options: nosniff prevents browsers from "sniffing" the response and overriding your declared Content-Type. Without it, a browser might decide your text/plain endpoint is actually JavaScript and execute it. The mitigation is one line of config; the alternative is occasional MIME-confusion bugs that produce CVEs.

Referrer-Policy: strict-origin-when-cross-origin controls how much information the browser sends in the Referer header. The default for most browsers is now this exact value, but setting it explicitly prevents older browsers from leaking full URLs (with query strings) to third parties. Use no-referrer if you have specific privacy requirements; strict-origin-when-cross-origin is the right balance for most sites.

Permissions-Policy (formerly Feature-Policy) controls which browser features can be used by your page and embedded iframes. Sensible defaults: disable geolocation, microphone, camera, USB, and serial unless you actually use them. The header is opt-in for everything — features not listed are allowed. The syntax is dense but standard: geolocation=(), microphone=(), camera=() disables all three for self and cross-origin.

For sites that legitimately need a feature, scope it: microphone=(self) lets your origin use the microphone but blocks embedded iframes. camera=(self "https://meet.example.com") allows yourself and a specific origin.

Cross-origin isolation is the post-Spectre/Meltdown answer to "how do we let pages use SharedArrayBuffer without enabling speculative-execution attacks". The model: a page can opt into a high-isolation mode where the browser guarantees no cross-origin window access and no untagged cross-origin resource loads. In exchange, the page gets back access to SharedArrayBuffer, high-resolution timers, and a few other capabilities.

COOP (Cross-Origin-Opener-Policy) controls window.opener access from cross-origin pages. The values are same-origin (block all cross-origin window access), same-origin-allow-popups (allow popups but block opener access from them), and unsafe-none (default, no protection). Most production sites should use same-origin.

COEP (Cross-Origin-Embedder-Policy) controls cross-origin resources you embed. The values are require-corp (every cross-origin resource must explicitly opt in via CORP header) and credentialless (a more permissive option introduced in 2022). Setting COEP require-corp is the strict choice; credentialless is the practical compromise that lets you embed third-party CDNs without coordinating CORP headers.

CORP (Cross-Origin-Resource-Policy) is set on resources you serve, not on pages you ship. It tells which other origins can embed your resource. same-origin is the strictest; cross-origin is the most permissive. Static assets that should be embeddable from anywhere (logo images, fonts) need cross-origin; sensitive endpoints should use same-origin.

Most sites do not need cross-origin isolation. The headers are only required if you use SharedArrayBuffer, high-resolution timers, or specific WebAssembly threading APIs. If you do not, COOP same-origin is the only one of the three you need to set, and it is essentially free.

Nginx uses add_header directives. Place them in a single include file and reference from each server block — this guarantees they apply uniformly. Note the always flag, which forces the headers on error responses too (without always, 4xx and 5xx responses skip them).

Caddy sets headers via the header directive. The Caddyfile syntax is much more compact than Nginx and supports per-route overrides naturally. Caddy 2 also automatically sets HSTS when it issues a TLS certificate — you only need to override if you want non-default settings.

Cloudflare can set headers via Transform Rules (free tier) or Workers (paid tier). Transform Rules are sufficient for static headers; Workers are needed for per-request CSP nonces. Cloudflare's "Security" → "HSTS" panel gives you a one-click HSTS deployment with sane defaults — the easiest path for any site already on Cloudflare.

If you are running a CDN in front of an origin, you have a choice about where to set headers. The CDN is more reliable (every response from the CDN is protected, including ones served from cache) but the origin has more context (it can vary the CSP per route, per user, per nonce). For a typical SaaS, set static headers (HSTS, X-Content-Type-Options, Permissions-Policy) at the CDN, and dynamic headers (CSP with nonce) at the origin.

X-XSS-Protection is deprecated. Modern browsers ignore it, and it actively hurt security in some cases (the browser's reflective XSS filter could be tricked into causing problems). Remove it if you have it.

X-Frame-Options is superseded by CSP's frame-ancestors directive. Setting both is fine for legacy browser support but unnecessary for modern stacks. If you have CSP, drop X-Frame-Options.

Public-Key-Pins (HPKP) was deprecated and removed from browsers in 2018-2019. Do not deploy it. The replacement (Expect-CT) was also deprecated in 2024 because Certificate Transparency is now mandatory for all certs. Just remove both.

Server, X-Powered-By, X-AspNet-Version: information disclosure headers that tell attackers what stack you are running. Suppress them. Nginx removes Server with a custom build (or more_clear_headers; Caddy removes it natively (-Server in headers); Cloudflare auto-strips them.

After deployment, verify externally. Mozilla Observatory (observatory.mozilla.org) gives a letter grade with detailed scoring. SecurityHeaders.com gives a similar grade with a simpler UI. Hardenize.com is more thorough but slower. CheckFast's SSL checker covers headers as part of a broader security audit.

Aim for A+ on both. A+ requires: HSTS with preload, CSP without unsafe-inline (or with nonce-based strict-dynamic), X-Content-Type-Options, Referrer-Policy, COOP, and a Permissions-Policy listing at least one disabled feature.

B-grade results almost always trace to one of: CSP with unsafe-inline and unsafe-eval; HSTS without preload directive; missing X-Content-Type-Options. Each is a one-line config fix. The fact that B-grade is the production median for SaaS sites in 2026 is mostly a story of teams shipping something good enough and not iterating.

Run the validators monthly. New CSP violations and new third-party integrations both produce regressions, and the validators catch them within minutes. Wire securityheaders.com into your CI as a smoke test if you want continuous verification.