HTTP Security Headers Explained (2026)

HTTP security headers are directives a server sends with every response that tell the browser how to behave defensively: enforce HTTPS, refuse to be framed, block MIME sniffing, restrict what scripts can load, and limit what powerful APIs a page may use. They are the highest return-on-effort control in web security because they cost nothing to add, apply globally, and turn the browser itself into an enforcement point. The catch is that they are opt-in. A response with no security headers is a response that trusts the browser's permissive defaults, and attackers know exactly how to exploit those defaults.

The short answer for 2026: send Strict-Transport-Security to lock in HTTPS, a Content-Security-Policy to constrain resource loading, X-Content-Type-Options: nosniff to stop MIME sniffing, frame-ancestors in your CSP (with X-Frame-Options as a legacy backstop) to prevent clickjacking, a strict Referrer-Policy, and a Permissions-Policy to disable APIs you do not use. Below is what each header does and the value to set.

The core headers

Start with transport security. HSTS tells the browser to only ever connect to your origin over HTTPS, eliminating the downgrade window after the first visit.

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

Next, stop the browser from guessing content types, which is how a text upload can be coerced into executing as script.

X-Content-Type-Options: nosniff

Clickjacking defense comes from your CSP frame-ancestors directive, which supersedes the old X-Frame-Options header. Send both for now, since some older embedded contexts still honor only the legacy header.

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

Control how much of your URL leaks to other sites through the referrer, and disable device and browser capabilities you never use so a script injection cannot reach them.

Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=()

Cross-origin isolation and caching

For applications that use powerful features like SharedArrayBuffer, or that simply want to harden against cross-origin attacks, the Cross-Origin headers matter. Cross-Origin-Opener-Policy severs the link between your window and any window that opened it, and Cross-Origin-Resource-Policy prevents other origins from embedding your resources.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

Do not overlook caching. Sensitive responses, anything containing personal data, tokens, or account state, should never be cached by shared proxies. A misconfigured cache serving one user's authenticated page to another is a real and recurring breach class.

Cache-Control: no-store

Reference table

A word on legacy headers: X-XSS-Protection is obsolete and should be omitted or set to 0, because the browser filters it controlled were removed and could themselves introduce vulnerabilities. Rely on CSP instead.

Verify, do not assume

The most common failure is not a wrong header value; it is a header that silently disappeared. A framework upgrade, a new reverse proxy, or a CDN rule can strip headers you thought were fixed months ago. Verify from the outside on a schedule, not once during setup.

# Inspect the headers a live endpoint actually returns
curl -sI https://example.com | grep -iE 'strict-transport|content-security|x-content-type|referrer|permissions-policy'

Wire this into CI against a preview deployment so a missing header fails the pipeline before it reaches production.

How Safeguard helps

Header configuration is a runtime property of your deployed application, which is exactly what dynamic testing observes. Safeguard's dynamic application security testing probes your live endpoints and flags missing or weak security headers alongside other runtime findings, so a stripped HSTS or absent CSP shows up as a tracked issue rather than a surprise in a pen test. Griffin AI turns those findings into concrete remediation guidance, and the Safeguard CLI lets you assert header presence against preview builds in CI. Because headers are only one layer, Safeguard pairs runtime testing with software composition analysis of the libraries behind your responses, and teams comparing platforms can review the pricing.

Catch missing security headers before your users do: get started free or read the documentation.

Frequently Asked Questions

Which HTTP security headers are essential in 2026?

At minimum: Strict-Transport-Security to enforce HTTPS, a Content-Security-Policy to constrain resource loading and framing, X-Content-Type-Options: nosniff to stop MIME sniffing, a strict Referrer-Policy, and a Permissions-Policy disabling unused browser features. Add the Cross-Origin family for applications that need cross-origin isolation.

Is X-Frame-Options still needed if I use CSP frame-ancestors?

The CSP frame-ancestors directive is the modern, more expressive control and takes precedence in browsers that support it. Keep X-Frame-Options: DENY as a legacy backstop for now, since a few older embedding contexts still honor only that header, but treat frame-ancestors as the primary defense.

Should I still send X-XSS-Protection?

No. The browser XSS filters it controlled have been removed and could themselves be abused, so the header is obsolete. Omit it or set it to 0, and rely on a strict Content-Security-Policy for cross-site scripting defense instead.

How do I make sure my security headers do not silently disappear?

Verify them from the outside on a schedule rather than once at setup, because a framework upgrade, proxy change, or CDN rule can strip them. Add an automated check, for example a curl -I assertion or a DAST scan, against a preview deployment so a missing header fails CI before release.