Security Guides
Security headers are not a list to stack — what still works, what is obsolete, and what now does harm
Most security-header lists online stopped being updated and still recommend headers that are gone. MDN marks X-XSS-Protection deprecated and non-standard, and warns it can create XSS vulnerabilities in otherwise safe websites. Which headers to set today, and which to remove.
Example header configurations are everywhere. The problem is that most of them stopped being updated. Copy a list that was correct a few years ago and you bring in headers that have outlived their purpose — and one that can actively do harm.
① The six worth setting today
Our security header scanner grades against these six. Deprecated headers are deliberately excluded.
- Content-Security-Policy
- Declares where scripts and resources may come from. The core control that narrows what an XSS can do. Its
frame-ancestorsalso governs embedding - Strict-Transport-Security
- Tells the browser to always come back over HTTPS, closing the first plaintext request (
max-ageplusincludeSubDomains) - X-Frame-Options
- Refuses framing by other sites — clickjacking defense. In practice it is set alongside CSP's
frame-ancestors - X-Content-Type-Options
nosniff. Stops the browser guessing a type from the content, which reduces incidents where an uploaded file is interpreted as something it should not be- Referrer-Policy
- Limits the referrer passed onward, reducing leakage of whatever ended up in a URL (on the assumption you never put secrets there in the first place)
- Permissions-Policy
- Disables browser capabilities by default — camera, microphone, geolocation. Close what you do not use
Order matters: start with what cannot break anything
X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy are reliable and unlikely to break rendering, so they can go in first. Strict-Transport-Security should wait until HTTPS works on every path — it is remembered by browsers, which makes backing out awkward.
CSP comes last, and gradually. Its blast radius is the largest, and going strict in one step will break legitimate functionality. Build it up with the CSP builder.
② What has outlived its purpose
Expect-CT: mostly obsolete since June 2021
MDN marks this header Deprecated and explains that only Google Chrome and other Chromium-based browsers implemented it, and Chromium has deprecated the header from version 107, because Chromium now enforces CT by default. A note on the same page adds that "the Expect-CT is mostly obsolete since June 2021".
In other words, the browser started doing it by default, so there is nothing left for the site to instruct. No reason to add it to anything new.
③ What can now do harm
X-XSS-Protection: deprecated, non-standard, and able to create XSS
MDN carries both a Deprecated and a Non-standard banner on this header, plus a warning: "Even though this feature can protect users of older web browsers that don't support CSP, in some cases, X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites."
Its recommendation is unambiguous: "It is recommended that you use Content-Security-Policy instead of XSS filtering."
This is the decisive case against "more headers is better". A setting added in good faith can, in the right circumstances, become the attack surface. If you do not send it, do not add it; if you already do, plan its removal. For the underlying flaw, see what XSS is.
What a stale list looks like
CSP, HSTS, X-Frame-Options and nosniff — plus
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …
It is a longer list, and some scanners may even score it higher. Against current browsers, though, those extra entries are either inert or capable of harm.
What practice looks like now
CSP at the centre, the other five supporting it.
Deprecated headers are not added, and removed where present. Effort spent on the quality of the CSP — specifically how much 'unsafe-inline' you have eliminated — buys far more real defense than lengthening the list.
The premise: headers do not close holes
Application defects (XSS, missing authorization, uploads)
no number of headers removes these
↓ when one occurs
What headers govern
where data may be sent · whether the page can be framed · whether plaintext is allowed = limiting the spread
Adding CSP to a site with an XSS flaw does not remove the XSS; it narrows what can be done with it. So the order is: fix the application defect, then layer headers on as one more line. And the converse holds — a perfect header score is not evidence of a safe site.
Checking your own site
Measure what is actually being returned
Read the responses, not the config files. Reverse proxies, CDNs, frameworks and the application itself all add or overwrite headers, so what is configured and what is sent are not always the same. Our header scanner measures a URL directly.
Look for deprecated headers in the output
If X-XSS-Protection or Expect-CT come back, plan to remove them. The first especially — as above, it is documented as capable of creating a vulnerability.
Add the four that cannot break anything
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy closing capabilities you do not use. Reliable, and unlikely to affect rendering.
Save HSTS until HTTPS is fully working
Strict-Transport-Security is remembered by the browser, so enabling it while HTTPS is still shaky makes recovery painful. Confirm every path serves HTTPS first. Certificate basics are in what Let's Encrypt is.
Introduce CSP gradually, then go for the real prize
Start permissive and tighten, with removing 'unsafe-inline' as the objective — that is the fork in the road that decides how much CSP is worth. Build it with the CSP builder, and review the rest of the security baseline checklist while you are there.
This site's view: with copied configuration, freshness is the whole lifespan
Security headers are the archetypal copy-and-paste setting, which is exactly why how old the source is determines how safe the result is. Both headers in this article were once correct. X-XSS-Protection went further than that: the recommendation of its day is the warning of today.
Our position is to treat header configuration as a setting you revisit occasionally, not a task you complete once — and not to aim at a scanner's score, since a score can rise from adding a deprecated header. Spend the time on the quality of your CSP rather than the length of the list.
Sources (primary)
- MDN Web Docs, "X-XSS-Protection" — developer.mozilla.org (the Deprecated and Non-standard banners, the warning that it can create XSS vulnerabilities in otherwise safe websites, and the recommendation to use CSP instead)
- MDN Web Docs, "Expect-CT" — developer.mozilla.org (the Deprecated banner, the Chromium 107 deprecation and its reason, and the note that it is mostly obsolete since June 2021)
Both checked on 5 September 2026.
Read next
- Tools: security header scanner / CSP builder
- Glossary: what XSS is / what clickjacking is / what CORS is
- Foundation: the security baseline checklist
FAQ
QShould I set X-XSS-Protection?
No. MDN marks this header both Deprecated and Non-standard, and warns that even though it can protect users of older browsers that do not support CSP, in some cases X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites. Its recommendation is explicit: use Content-Security-Policy instead of XSS filtering. If you do not send it, do not add it; if you do, plan to remove it.
QIs Expect-CT still needed?
No. MDN marks it Deprecated and explains that only Google Chrome and other Chromium-based browsers implemented it, and that Chromium deprecated the header from version 107 because Chromium now enforces Certificate Transparency by default. A note on the same page states the header is mostly obsolete since June 2021. There is no reason to add it to anything new.
QSo which ones should I set?
The six our header-scanning tool grades against are a practical starting point: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Deprecated headers are deliberately not in that set. On ordering, add the ones that are reliable and unlikely to break anything first (nosniff, X-Frame-Options), and introduce CSP gradually because its blast radius is the largest.
QIf I set every header, is the site secure?
No. Headers do not close holes in your application; they limit how far damage spreads. Adding CSP to a site with an XSS flaw does not remove the XSS — it narrows what can be done with it. Fix the application defect first and layer headers on as one more line of defense. And the converse: a perfect score from a header scanner is not evidence that a site is safe.