Web Security Headers Fundamentals

HTTP response headers are the primary mechanism for instructing browsers on how to enforce transport security, restrict resource execution, and limit information leakage. For developers, sysadmins, and security engineers, a coherent header strategy is a non-negotiable baseline for modern application defense. This reference establishes production-ready configurations aligned with current browser security models, with explicit security trade-offs for each deployment decision. The detailed mechanics of individual controls live in the dedicated references for Content Security Policy, HTTP Strict Transport Security, and cross-origin isolation with COOP, COEP, and CORP.

Security headers are not a monolith. They are enforced at different layers of the request path, by different actors, and under different caching semantics. Some headers — like Strict-Transport-Security — are remembered by the browser for months after a single response. Others — like a per-request Content-Security-Policy nonce — must be regenerated on every response or the policy is silently defeated. Treating all headers as one undifferentiated block of add_header lines is the single most common cause of misconfiguration. The phased strategy below sequences them by blast radius: transport first, then injection control, then framing, then privacy, then legacy cleanup, then telemetry.

Security Scope & Operational Boundaries

This reference covers HTTP response header configuration at the edge, reverse-proxy, and application levels, TLS 1.2/1.3 handshake enforcement that underpins transport headers, and the browser security-context controls those headers activate (framing, resource isolation, cross-origin policies). It establishes the order of deployment, the cross-platform syntax, and the verification commands that confirm each control is live.

It explicitly excludes application-layer input sanitization, output encoding, parameterized queries, database encryption at rest, secrets management, and network-perimeter firewall configuration. Header enforcement is a defense-in-depth control: a strict Content-Security-Policy reduces the impact of an XSS bug but does not fix the bug, and it does not protect against server-side injection, SSRF, or broken authentication. Headers constrain what a browser will do with a response; they have no effect on non-browser API clients, server-to-server traffic, or native mobile apps that do not run a web engine. Treat the controls here as the browser-facing surface of a broader security program, not the whole program.

Auditing and ongoing measurement are treated as a first-class concern, covered in depth in the security header auditing and compliance reference and its companion security header audit checklist. Platform-specific syntax beyond the Nginx and Apache examples here — including Cloudflare, IIS, Node/Express, Next.js, and Django/FastAPI — is documented in the server and platform implementation guides.

Core Threat Model

Security headers directly address well-documented attack vectors by constraining browser behavior and enforcing strict origin policies. Each row below maps a real-world attack class to the header that neutralizes or materially reduces it. The mitigation is only as strong as its configuration — an unsafe-inline script source, a short HSTS max-age, or a missing always flag can render the control cosmetic.

The two recurring failure modes across all categories are partial coverage (the header is present on the document but missing on API, error, or redirect responses) and cache contamination (a stale or duplicated header is served from an intermediary). The always flag in Nginx and Apache, addressed in every phase below, exists specifically to close the partial-coverage gap.

Phased Deployment Strategy

Deploying security headers requires a structured, ordered approach to prevent service disruption while progressively hardening the application surface. Each phase is independently deployable and independently verifiable. Roll out one phase to a staging environment, verify it with the listed commands, then promote it before starting the next. Never deploy CSP enforcement and HSTS preload in the same change — if something breaks you must be able to attribute it.

Phase 1: Enforce HTTPS & Transport Security

Objective: Establish baseline TLS integrity and make protocol downgrade impossible after the first visit.

The foundation of every other header is an encrypted, authenticated transport. A Strict-Transport-Security (HSTS) header instructs the browser to refuse plaintext HTTP to your origin for the duration of max-age, eliminating the sslstrip window that exists on the very first navigation only if you also submit to the preload list. Start with a short max-age (for example 300) in staging, confirm no subdomain or mixed-content breakage, then raise it to two years and add preload only when every subdomain serves valid TLS. Preload is effectively irreversible on a useful timescale, so it is the last toggle you flip, not the first. Detailed max-age and includeSubDomains rollout sequencing lives in how to configure max-age and includeSubDomains for HSTS and the preload vs manual enforcement trade-offs.

HSTS is only honored over HTTPS, so the header on an HTTP response is ignored — you must also redirect HTTP to HTTPS with a 301. Set the header at the outermost TLS-terminating layer (your CDN or edge); on Cloudflare, enable HSTS under SSL/TLS → Edge Certificates rather than via a header rule, which keeps a single source of truth.

Server Configuration:

# In the server { } block that listens on 443
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# `always` emits the header on 4xx/5xx and redirect responses too, not just 200s.

# In the <VirtualHost *:443> block, requires mod_headers
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
# `always` ensures error responses also carry the header.

Verification Steps:

• Confirm the TLS handshake and protocol: openssl s_client -connect example.com:443 -tls1_2 </dev/null returns a valid certificate chain.
• Confirm the redirect: curl -sI http://example.com shows HTTP/1.1 301 with a Location: of https://example.com.
• Confirm the header on HTTPS: curl -sI https://example.com | grep -i strict-transport returns the full directive string including includeSubDomains.
• Confirm the header survives errors: curl -sI https://example.com/this-404s | grep -i strict-transport still returns it (validates always).

Phase 2: Resource Isolation & Script Execution Control

Objective: Restrict where executable code and assets may originate and neutralize client-side injection.

A Content-Security-Policy is the highest-value and highest-risk header you will deploy. It defines an allowlist of sources per resource type, and a strict policy reduces a stored-XSS payload from “full account takeover” to “blocked script, console warning, violation report.” The non-negotiable goal is to remove 'unsafe-inline' from script-src, which requires either a per-request nonce (see generating CSP nonces per request) or hashes of known inline scripts (see hash-based CSP for inline scripts). For large applications with many third-party scripts, pair a nonce with strict-dynamic so trusted scripts may load their own dependencies without enumerating every CDN host.

The nonce must be unique per response and unguessable, which means it cannot be set by a static add_header line — it must come from the application layer, with the proxy passing it through. Pair CSP with X-Content-Type-Options: nosniff, which stops the browser from MIME-sniffing a response into an executable type and is a hard requirement for several CSP and CORB protections to work. Always deploy in Content-Security-Policy-Report-Only first and collect violations before enforcing.

Server Configuration:

# Nonce ($csp_nonce) is generated by the app and exposed to nginx; never hardcode it.
add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-$csp_nonce' 'strict-dynamic'; object-src 'none'; base-uri 'self'; style-src 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
# `always` keeps the policy on every response so injected error pages are covered too.

# Requires mod_headers; %{CSP_NONCE}e is set by the app via SetEnvIf / mod_setenvif.
Header always set Content-Security-Policy "default-src 'self'; script-src 'nonce-%{CSP_NONCE}e' 'strict-dynamic'; object-src 'none'; base-uri 'self'; style-src 'self'; frame-ancestors 'self'"
Header always set X-Content-Type-Options "nosniff"

Verification Steps:

• Ship report-only first: curl -sI https://example.com | grep -i content-security-policy-report-only returns the policy, and the enforcing header is absent.
• Confirm the nonce rotates: request the page twice and diff the nonce- value — it must differ each time.
• Collect violations for 48–72 hours via report-to/report-uri before switching to the enforcing Content-Security-Policy header.
• After enforcing, verify blocked resources produce a console violation and a report, but the page still renders its critical path.

Phase 3: Framing Restrictions & UI Redressing Prevention

Objective: Block unauthorized embedding of your pages to defeat clickjacking.

Clickjacking loads your page in an invisible iframe over attacker-controlled UI so victims click your buttons unknowingly. The modern control is the CSP frame-ancestors directive; the legacy control is X-Frame-Options. Set both: frame-ancestors is authoritative in every current browser and supports an explicit allowlist of permitted embedders, while X-Frame-Options: SAMEORIGIN covers older clients. Where the two disagree, modern browsers honor frame-ancestors. The differences and migration path are detailed in X-Frame-Options vs CSP frame-ancestors; if a legitimate partner integration breaks, see fixing X-Frame-Options blocking legitimate iframes.

X-Frame-Options has no multi-origin allowlist — the deprecated ALLOW-FROM value is unsupported — so any allowlist beyond same-origin must live in frame-ancestors. On IIS, set both via <httpProtocol><customHeaders> in web.config; on Cloudflare, prefer a Transform Rule so the value is consistent across cached and dynamic responses.

Server Configuration:

add_header X-Frame-Options "SAMEORIGIN" always;
# frame-ancestors belongs in the CSP from Phase 2; shown standalone here for clarity:
# add_header Content-Security-Policy "frame-ancestors 'self' https://partner.example.com" always;

Header always set X-Frame-Options "SAMEORIGIN"
# Prefer extending the existing CSP with: frame-ancestors 'self' https://partner.example.com

Verification Steps:

• curl -sI https://example.com | grep -i x-frame-options returns SAMEORIGIN.
• Build a one-line test page that embeds your site in an <iframe> from a different origin and confirm the frame is blank (refused) in Chrome and Firefox.
• Confirm frame-ancestors is present in the CSP and lists only intended embedders; verify any partner integration still loads.

Phase 4: Privacy Controls & Hardware Feature Delegation

Objective: Stop leaking referrer data and revoke browser hardware APIs you do not use.

By default, navigating from a secure page can leak the full URL — including path and query — in the Referer header to third parties, exposing session tokens, reset links, and internal structure. Referrer-Policy: strict-origin-when-cross-origin sends the full URL same-origin, only the origin cross-origin over HTTPS, and nothing on a downgrade to HTTP; the rationale and stricter alternatives are covered in setting Referrer-Policy strict-origin-when-cross-origin. Separately, Permissions-Policy lets you disable powerful features — camera, microphone, geolocation, payment, USB — for your own origin and all embedded frames, shrinking the attack surface a compromised third-party script can reach. Disable everything you do not actively use; see Permissions-Policy disabling browser features for the full feature list and allowlist syntax.

The empty-allowlist form feature=() disables a feature entirely, including for your own origin; feature=(self) keeps it for first-party use only. Mis-scoping here silently breaks embedded media players, payment widgets, and map components, so confirm what your front end actually calls before locking down.

Server Configuration:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always;

Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()"

Verification Steps:

• Navigate cross-origin and inspect the outgoing request in DevTools Network tab: the Referer header shows only https://example.com, not the full path.
• In the console, navigator.geolocation.getCurrentPosition(()=>{}, e=>console.log(e)) rejects with a permissions-policy error when geolocation is disabled.
• Confirm analytics and any embedded media still function; mis-scoped Permissions-Policy is the usual culprit when a player goes silent.

Phase 5: Legacy Header Audit & Deprecation Management

Objective: Remove headers that are deprecated, harmful, or that fingerprint your stack.

Older hardening advice still circulates, and some of it now actively hurts. X-XSS-Protection drove a browser filter that has been removed from Chrome and Edge and that, in its 1; mode=block form, introduced its own information-leak bugs — set it to 0 to disable any residual behavior so it cannot interfere with CSP. HPKP (Public-Key-Pins) is fully deprecated and a notorious self-DoS foot-gun; remove it entirely and never reintroduce it. Finally, strip identifying headers like Server and X-Powered-By that hand attackers your exact software versions. The full deprecation map and migration guidance is in deprecated headers and legacy browser support, and the safe removal procedure for fingerprinting headers is in removing X-Powered-By and Server headers safely.

Removing the Server token in Nginx requires the more_clear_headers directive from the third-party headers-more module (or server_tokens off to at least drop the version); in Apache use ServerTokens Prod and Header unset. On Cloudflare these tokens are largely normalized at the edge, but verify rather than assume.

Server Configuration:

# Disable the obsolete XSS filter so it can't conflict with CSP
add_header X-XSS-Protection "0" always;
# Never set Public-Key-Pins — it is deprecated and dangerous
server_tokens off;                 # drop the Nginx version from the Server header
# more_clear_headers "Server";     # full removal needs the headers-more module

Header always set X-XSS-Protection "0"
ServerTokens Prod                  # reduce the Server header to "Apache"
Header always unset X-Powered-By   # strip the app-server fingerprint
# Ensure no Header set Public-Key-Pins lines remain anywhere

Verification Steps:

• Run a scan against production with the auditing references and confirm no Public-Key-Pins and no X-XSS-Protection: 1; mode=block.
• curl -sI https://example.com | grep -iE 'server|x-powered-by' shows no version numbers.
• Walk the full security header audit checklist to confirm each control is present, scoped, and free of deprecated directives.

Phase 6: Cross-Origin Isolation & Violation Telemetry

Objective: Opt into a stronger isolation tier where required, and capture policy violations continuously.

Two distinct hardening tasks complete the rollout. First, if your application needs high-resolution timers or SharedArrayBuffer — common for WebAssembly, video processing, or analytics — the browser gates them behind cross-origin isolation, which you enable with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. COOP severs the window.opener relationship to defeat cross-window attacks; COEP forces every embedded resource to explicitly opt in via CORP or CORS. This is a breaking change for any page that loads third-party resources without those headers — work through enabling cross-origin isolation for SharedArrayBuffer and keep debugging COEP-blocked resources handy. Even when you do not need isolation, set Cross-Origin-Opener-Policy: same-origin for its standalone clickjacking and cross-window protection.

Second, make violation telemetry permanent. Keep a Content-Security-Policy-Report-Only policy running alongside the enforcing one to catch regressions, and pipe both to a reporting endpoint via report-to. The endpoint setup and the report-uri → report-to migration are covered in the CSP report-uri vs report-to migration guide, and a CI/CD scanning pipeline is described in automated header scanning in CI/CD.

Server Configuration:

add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Embedder-Policy "require-corp" always;   # only when isolation is required
add_header Reporting-Endpoints 'csp-endpoint="https://example.com/csp-report"' always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-to csp-endpoint" always;

Header always set Cross-Origin-Opener-Policy "same-origin"
Header always set Cross-Origin-Embedder-Policy "require-corp"
Header always set Reporting-Endpoints "csp-endpoint=\"https://example.com/csp-report\""
Header always set Content-Security-Policy-Report-Only "default-src 'self'; report-to csp-endpoint"

Verification Steps:

• self.crossOriginIsolated === true in the console confirms COOP+COEP took effect (only after both headers are present).
• Trigger an intentional violation and confirm a report arrives at the endpoint with the expected JSON csp-report body.
• Confirm the report-only policy stays in place after enforcement so future regressions surface as reports, not outages.

Security Trade-offs & Operational Considerations

Strict headers create real, measurable tensions that you must resolve deliberately rather than accept by default. The dominant ones:

• CSP strictness vs third-party breakage. Removing 'unsafe-inline' is the entire point of CSP, but it breaks inline event handlers, inline <style> attributes, and tag-manager-injected scripts. Resolve it with nonces plus strict-dynamic, never by re-adding 'unsafe-inline' — which silently disables nonce enforcement when both are present. Budget engineering time to refactor inline handlers; there is no header-only shortcut.
• HSTS preload vs reversibility. includeSubDomains; preload is effectively a one-way door: removal requires a browser-vendor delisting cycle measured in months, during which a single subdomain without valid TLS becomes unreachable. The trade-off is maximal downgrade protection in exchange for an operational commitment that every current and future subdomain serves HTTPS. Earn it with a short max-age soak first.
• Cross-origin isolation vs the open web. COEP require-corp unlocks SharedArrayBuffer but rejects every third-party image, font, or script that does not send CORP/CORS headers. For a content-heavy site pulling many external assets, the cost of auditing and re-hosting can exceed the benefit unless you genuinely need the isolated APIs. Adopt COOP for its standalone value and add COEP only where the feature gate demands it.
• Permissions-Policy lockdown vs functionality. The empty-allowlist form disables features for your own origin too, so an over-eager payment=() or camera=() breaks checkout flows and video calls. Inventory what the front end calls before disabling, and prefer (self) over () for features used first-party.
• Edge vs application ownership. Setting headers at the CDN is operationally clean but cannot produce per-response values like CSP nonces, and duplicating a header across the CDN and the proxy can cause the browser to apply the most restrictive value or reject the response. Decide the owning layer per header and assert it in your audits.
• Report-only fatigue vs enforcement. Report-only mode is safe but produces high-volume noise from browser extensions and crawlers; teams that never graduate to enforcement get the monitoring cost without the protection. Set a fixed soak window, triage the genuine violations, then enforce.

Resolve these by sequencing changes through staging with a short max-age, leaning on report-only telemetry, owning each header at exactly one layer, and validating continuously in CI rather than once at launch. Defense-in-depth requires the headers here to be one verified, monitored layer among many — not a launch-day checkbox.

Related

• Content Security Policy essentials — the injection-control core of any header strategy.
• HTTP Strict Transport Security deep dive — transport enforcement, max-age, and preload.
• Cross-origin frame controls and X-Frame-Options — clickjacking defense and frame-ancestors.
• Referrer-Policy and Permissions-Policy explained — privacy and hardware-feature controls.
• Cross-origin isolation: COOP, COEP, CORP — the isolation tier for SharedArrayBuffer and side-channel defense.
• Cache-Control and Clear-Site-Data — preventing stale credential and cache exposure.