HTTP security headers: which ones matter and what to set them to

What headers can and cannot do

Security headers are instructions to the browser about how to treat your site. That framing matters, because it defines the limit: they reduce the damage of a vulnerability, they do not remove it. A CSP can stop an injected script from executing; it does not stop the injection. Headers are a second line, not the first.

They are also unusually cheap. Most are one line of configuration, apply site-wide, and never change again. That combination — low cost, real mitigation — is why they are worth doing properly rather than approximately.

The short list, with starting values

Two of these deserve more than a table row.

HSTS: the one you cannot undo quickly

Strict-Transport-Security tells the browser to refuse plain HTTP for your domain for the given number of seconds. It is one of the most effective headers there is — and the only one on this list with a genuinely painful failure mode, because the browser remembers it and there is no way to reach the users who already have.

Roll it out in stages:

1. max-age=300 — a few minutes, to confirm nothing breaks.
2. max-age=31536000 — one year, once you are confident.
3. ; includeSubDomains — only after verifying that every subdomain serves HTTPS. This is where people get caught: a legacy status. or mail. host on plain HTTP becomes unreachable, for a year, for everyone who visited once.
4. ; preload — only when you are prepared for that commitment to be effectively permanent.

CSP: shipping one without breaking your site

Content-Security-Policy is the most valuable header and the most likely to break things, because it requires you to know exactly what your pages load. The way through is to let the browser tell you.

Start in report-only

Send Content-Security-Policy-Report-Only instead of Content-Security-Policy. The browser evaluates the policy exactly as it would if enforcing, logs every violation to the console, and blocks nothing. Start strict:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Widen only where the violations are real

Browse the site — every template, not just the homepage — and read the violations. Each one is either something you genuinely load, which you add to the policy, or something you did not know you loaded, which is worth a second look. Analytics, ad scripts, embedded fonts and third-party widgets all surface here.

Deal with inline script deliberately

Inline <script> blocks are the usual reason people give up and add 'unsafe-inline', which removes most of the benefit. The alternatives:

• Hashes. Compute the SHA-256 of each inline block and list it in script-src. Ideal for a static site, where the set is fixed at build time and can be generated automatically.
• Nonces. Emit a fresh random value per response, put it on each allowed script tag and in the policy. Necessary when the inline content varies per request.

Either way, the goal is a script-src with no 'unsafe-inline' and no 'unsafe-eval'.

Then enforce

When report-only has been quiet across the whole site for a while, change the header name. Keep the report-only version alongside if you want to test further tightening without risk — the two can be sent together.

Permissions-Policy

Permissions-Policy (formerly Feature-Policy) disables browser features for your page and anything it embeds. An empty allowlist () means "nobody, including me":

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

Listing features you never use costs nothing and removes them as an avenue for embedded content. If your own page needs one, use self: fullscreen=(self).

The cross-origin isolation trio

COOP, COEP and CORP are frequently recommended together by scanners, which is misleading — they solve a narrower problem (cross-origin data leaking through side channels) and COEP in particular breaks third-party embeds that do not send the matching headers.

• Cross-Origin-Opener-Policy: same-origin — safe on almost any site, and worth setting. It severs the window relationship with anything you open cross-origin.
• Cross-Origin-Resource-Policy: same-origin — good on resources you do not want other sites hotlinking. Do not apply it blindly to assets you intend to be embeddable.
• Cross-Origin-Embedder-Policy: require-corp — only if you need SharedArrayBuffer or precise timers. It will break ads, embedded video and most third-party widgets unless every one of them opts in.

Set COOP. Consider CORP per-resource. Leave COEP alone unless you have a specific reason.

Headers you can stop setting

• X-XSS-Protection — the browser XSS auditors it controlled have been removed. Modern guidance is 0, or simply not sending it; the filter itself introduced vulnerabilities.
• Public-Key-Pins — deprecated and removed. It caused more permanent outages than it prevented attacks.
• Expect-CT — obsolete; Certificate Transparency is enforced by browsers regardless.
• X-Powered-By, Server version strings — not a security control, but there is no reason to advertise your stack version. Remove them.

A scanner that still marks these missing is out of date. Which is the broader point: use a header check to find what you have forgotten, not as a score to maximise.

Spotted an error in this guide? Tell us at [email protected] — corrections are made and the updated date above changes with them.