CentralCSP
Security headers

HTTP security headers, the complete list explained

What HTTP security headers are, the full list with status and what each protects against, and where each one is documented.

Last update:

Security headers are HTTP response headers that tell the browser how to protect the page and the people using it. Your server sends them with each response, and the browser does the enforcing: blocking injected scripts, refusing plain HTTP, keeping the session cookie away from other sites.

Most of them take one line of server configuration. This page is the full list, with each header's status, what it protects against, and the action to take, linking to the page that covers it in depth. The natural first step is to run your own site through the security headers scanner and see which of these you already send.

The security headers at a glance

HeaderStatusProtects againstAction
Content-Security-Policy✅ GoodXSS, injection, exfiltrationDeploy via report-only first
Strict-Transport-Security✅ GoodSSL stripping, cleartext hopsmax-age=63072000; includeSubDomains
Set-Cookie attributes✅ GoodSession theft, CSRF__Host- + Secure + HttpOnly + SameSite
X-Content-Type-Options✅ GoodMIME-sniffing XSSnosniff on every response
Referrer-Policy✅ GoodURL leaks to third partiesstrict-origin-when-cross-origin
Cache-Control✅ GoodCached sensitive pagesno-store on personal data
Cross-Origin-Resource-Policy✅ GoodSpectre-class leaks, hotlinkingsame-site
Cross-Origin-Opener-Policy✅ GoodWindow takeover, XS-Leakssame-origin
Cross-Origin-Embedder-Policy✅ GoodCross-origin data in your processrequire-corp for isolation
Permissions-Policy🧪 ExperimentalUnwanted camera, mic, geolocation useDeny unused features
X-Frame-Options✅ GoodClickjacking in old browsersDENY alongside frame-ancestors
Server, X-Powered-By and friends❌ RiskyThey leak your stackRemove them
X-XSS-Protection⚠️ DeprecatedNothing (its filter caused XSS)Remove; use CSP
Feature-Policy⚠️ DeprecatedReplaced by Permissions-PolicyMigrate
Public-Key-Pins / Expect-CT⚠️ DeprecatedDead TLS experimentsRemove

How to read the table

  • Good means fine to ship in production; the Action column is the value to send.
  • Risky means the header itself is the problem; sending it weakens your position, so the action is to remove it.
  • Experimental means not fully standardized or limited to some browsers; the Permissions-Policy header is Chromium-only, though other browsers ignore it harmlessly.
  • Deprecated means browsers removed or replaced it; the row names what to do instead.

Each header has exactly one page, and the row links there wherever it lives. Content Security Policy and the other report-emitting policies are documented in the Policies section, the delivery of their reports in the Reporting API section, and the rest in this section.

Where to start

For a site that sends none of these, this order pays off fastest:

  1. Scan the site with the security headers scanner to see what you send today.
  2. Ship the one-liners: Strict-Transport-Security, X-Content-Type-Options, and Referrer-Policy.
  3. Harden the session cookie with the Set-Cookie attributes, starting from __Host- plus Secure, HttpOnly, and SameSite.
  4. Deploy a Content Security Policy in report-only mode and tighten it from the reports before enforcing.
  5. Add the cross-origin pair, Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy.
  6. Remove what the table marks Risky or Deprecated: the disclosure banners and the dead TLS headers.

See also

Legacy

Older security headers like X-Frame-Options and Feature-Policy, what replaced them, and whether you still need to send them.

Strict-Transport-Security

The HSTS header pins HTTPS for future visits so the browser never retries plain HTTP. What it protects against and how to deploy it safely.

On this page

The security headers at a glanceHow to read the tableWhere to startSee also