HTTP Security Headers Checklist 2026 — Complete Audit Guide — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
← All posts
April 8, 2026

HTTP Security Headers: The Complete Audit Checklist for 2026

Security headers are one of the cheapest wins in web security. A dozen lines of server configuration can block XSS, clickjacking, MIME sniffing, cross-origin data leaks, and a range of browser-level attacks. The problem isn’t knowing that headers matter — most developers do. The problem is knowing which ones to set, what values are correct, and how to verify the headers your server is actually sending.

This is that checklist.

Each entry covers what the header does, the recommended value, common misconfiguration patterns, and how to inspect it during development or audit. Use HeaderSnap to view and test headers directly in Chrome without spinning up a proxy or dedicated scanner.

How to Use This Checklist

Before going header-by-header: the fastest way to audit your security headers in Chrome is to open DevTools → Network tab, reload the page, select the document request, and look at the Response Headers panel. Every header below should appear there.

With HeaderSnap installed, you can also inject missing headers locally to test how your application behaves as if the header were set — useful for staging environments where headers haven’t landed yet.

The 10 Critical Security Headers

1. Content-Security-Policy (CSP)

What it does: Tells the browser which sources are allowed to load scripts, styles, images, fonts, and other resources. The primary defense against XSS.

Recommended baseline:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

What to check:

  • Is default-src or script-src present?
  • Is 'unsafe-inline' in script-src? If yes, XSS protection is largely negated.
  • Is 'unsafe-eval' in script-src? Needed for some frameworks but increases attack surface.
  • Is object-src 'none' set? Flash and plugin execution should be blocked.
  • Is there a report-uri or report-to directive for CSP violation logging?

Common misconfigurations: Setting script-src * (wildcard) defeats the purpose entirely. Starting with Content-Security-Policy-Report-Only for monitoring before enforcing is the correct approach for new implementations.

2. Strict-Transport-Security (HSTS)

What it does: Instructs browsers to only connect to your site over HTTPS — even if the user types http://. Once set, the browser refuses to make plain HTTP connections to that host for the duration of max-age.

Recommended value:

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

What to check:

  • Is max-age at least 31536000 (one year)? Shorter values provide minimal protection.
  • Is includeSubDomains present? Without it, subdomains are excluded.
  • Is preload included? Submit to the HSTS Preload list to bake HTTPS-only behavior into browsers before the first visit.

Common misconfigurations: Setting HSTS on a domain that also serves HTTP (or has a subdomain that does) — this causes load failures once the policy is cached.

3. X-Frame-Options

What it does: Controls whether your page can be embedded in an <iframe>. Blocks clickjacking attacks.

Recommended value:

X-Frame-Options: DENY

or, if same-origin framing is needed:

X-Frame-Options: SAMEORIGIN

What to check:

  • Is the header present?
  • Is ALLOWALL set? That’s equivalent to having no header.
  • Note: Content-Security-Policy: frame-ancestors is the modern replacement and takes precedence in browsers that support it. If both are set, frame-ancestors wins. Prefer CSP frame-ancestors for new implementations, but keep X-Frame-Options for older browser support.

4. X-Content-Type-Options

What it does: Prevents browsers from MIME-sniffing a response away from the declared Content-Type. Stops attacks where a file with one declared type is executed as another.

Value (only one valid option):

X-Content-Type-Options: nosniff

What to check: Is it present? Is it set to nosniff? There are no other valid values. If the header is missing, old browsers may try to infer content types — with exploitable results.

5. Referrer-Policy

What it does: Controls how much referrer information is included in the Referer header when navigating to other sites. Prevents leaking sensitive URL parameters (like session tokens in query strings) to third parties.

Recommended value:

Referrer-Policy: strict-origin-when-cross-origin

What to check:

  • Is the header present?
  • Is it set to no-referrer-when-downgrade (the old browser default)? That sends the full URL to HTTPS destinations, which may leak paths and parameters.
  • strict-origin-when-cross-origin sends the origin only (no path/query) for cross-origin requests, and nothing for HTTPS→HTTP downgrades.

6. Permissions-Policy

What it does: Controls which browser features and APIs your site (and embedded iframes) can use — camera, microphone, geolocation, payment, etc. The successor to Feature-Policy.

Recommended baseline:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

What to check:

  • Is the header present? Many sites skip this entirely.
  • Are features your app doesn’t use explicitly disabled?
  • Does the policy restrict iframe permissions?

Common misconfigurations: Omitting this header entirely leaves browser API access to browser defaults, which may be broader than intended.

7. X-XSS-Protection

What it does: Enables a built-in XSS filter in older browsers (IE, legacy Edge, pre-2019 Chrome). Modern browsers have removed or deprecated this filter.

Recommended value:

X-XSS-Protection: 0

What to check: Setting X-XSS-Protection: 1; mode=block is no longer recommended — the old XSS filter could be abused to selectively block page content. Explicitly disabling it with 0 is the current best practice. Your CSP is the modern XSS defense.

8. Cross-Origin-Opener-Policy (COOP)

What it does: Isolates your browsing context from cross-origin documents. Required for SharedArrayBuffer access and hardening against cross-origin attacks. Prevents opened windows from retaining a reference to your window.

Recommended value:

Cross-Origin-Opener-Policy: same-origin

What to check:

  • Is the header present?
  • Is it same-origin or same-origin-allow-popups? The latter allows cross-origin popups while still isolating the main context.
  • unsafe-none (the default) provides no isolation.

Common misconfigurations: Required alongside COEP if you need SharedArrayBuffer. Setting COOP without COEP (or vice versa) won’t enable cross-origin isolation.

9. Cross-Origin-Embedder-Policy (COEP)

What it does: Ensures all resources loaded by your page have opted into being loaded cross-origin. Works with COOP to enable cross-origin isolation — required for SharedArrayBuffer and high-resolution timers.

Recommended value:

Cross-Origin-Embedder-Policy: require-corp

What to check:

  • Is the header present?
  • Do third-party resources (CDN scripts, images, fonts) respond with Cross-Origin-Resource-Policy or CORS headers? COEP require-corp blocks resources that don’t explicitly allow cross-origin loading.
  • If resources break under require-corp, try credentialless first (looser, but enables isolation for most use cases).

10. Cross-Origin-Resource-Policy (CORP)

What it does: Prevents other origins from loading your resources (images, scripts, API responses) into their pages. Defense against cross-site leaks (Spectre-style side-channel attacks).

Recommended value:

Cross-Origin-Resource-Policy: same-origin

What to check:

  • Is the header set on your API responses and sensitive resources?
  • If you have a CDN serving public assets, cross-origin is appropriate (explicitly opting in to cross-origin loading).
  • Omitting this header allows any origin to embed your resources.

Auditing Headers with HeaderSnap

To audit any of these headers in Chrome:

  1. Install HeaderSnap (free, no account required)
  2. Open DevTools → Network tab
  3. Reload the page and select the main document request
  4. Check Response Headers for each header in this list

Where HeaderSnap adds value in an audit workflow: you can inject missing headers locally to test application behavior before they’re deployed. For example, add a strict Content-Security-Policy header via HeaderSnap, reload, and see which resources break — helping you build a policy incrementally without touching your server config.

Note: Chrome extensions can modify request headers and inject response headers for testing purposes. For production enforcement, headers must be set server-side.

Common Misconfigurations Summary

HeaderMost Common Mistake
CSPscript-src 'unsafe-inline' — negates XSS protection
HSTSmax-age too short (under 1 year)
X-Frame-OptionsMissing entirely; or ALLOWALL
X-Content-Type-OptionsMissing (no alternative to nosniff)
Referrer-Policyno-referrer-when-downgrade leaks URLs cross-origin
Permissions-PolicyNot set — browser API access unrestricted
X-XSS-Protection1; mode=block — use 0 instead
COOPunsafe-none (the default) — no isolation
COEPSet without CORP on third-party resources — breaks loads
CORPMissing on API responses — allows cross-site embedding

Quick Audit Checklist

Use this before deploying to production:

  • CSP is present with no unsafe-inline in script-src
  • HSTS max-age ≥ 31536000, includeSubDomains set
  • X-Frame-Options is DENY or SAMEORIGIN (or frame-ancestors in CSP)
  • X-Content-Type-Options is nosniff
  • Referrer-Policy is strict-origin-when-cross-origin or stricter
  • Permissions-Policy disables unused browser APIs
  • X-XSS-Protection is 0
  • COOP is same-origin (if cross-origin isolation needed)
  • COEP is require-corp (paired with COOP)
  • CORP is set on sensitive API responses

Security headers take less than an hour to audit and configure correctly. Use HeaderSnap to inspect response headers in Chrome without leaving your browser — install it free at headersnap.com.