No, you do not need either. Use a strong Content Security Policy instead of X-XSS-Protection, which MDN says can itself create XSS vulnerabilities. Expect-CT was deprecated in Chromium from version 107 because Certificate Transparency is now enforced by default. If an old scanner wants the first header, send 0.
X-XSS-Protection
This header controlled the XSS filter built into Internet Explorer, Chrome and Safari. MDN calls it non-standard and says the protections are largely unnecessary in modern browsers when a site implements a strong CSP that disables inline JavaScript.
More important, MDN warns that in some cases the filter can create XSS vulnerabilities in otherwise safe sites. Its example: a page defines a flag in one inline script and relies on it in later code. An attacker can craft a URL that makes the filter remove the first script, so the flag is undefined and unsafe debug code runs. Setting the header to 0 or 1; mode=block prevents that class of problem, though MDN notes the block mode has its own side channel risk if the site can be embedded in an iframe.
| Value | Effect |
|---|---|
0 | Disables the filter |
1 | Enables the filter and sanitises the page |
1; mode=block | Enables the filter and refuses to render |
Practical advice: send X-XSS-Protection: 0 if a compliance checklist insists on a value, and put the real work into a CSP and output encoding.
Expect-CT
Expect-CT let sites opt in to reporting or enforcement of Certificate Transparency requirements, which aim to stop misissued certificates going unnoticed. MDN states that only Chromium based browsers implemented it, and Chromium deprecated it from version 107, because Chromium now enforces CT by default. It also notes the header is mostly obsolete since June 2021, since all new certificates from May 2018 are expected to carry signed certificate timestamps.
Your certificates can still be monitored. CT logs are public, and you can watch for certificates issued for your domains using log monitoring, without any response header.
What to do about a scanner that flags them
- Check the scanner's rule. Many older rulesets list these as expected.
- Document why they are absent, citing the browser deprecation.
- Do not add Expect-CT back to satisfy a checklist. It has no effect in current browsers.
- If you must show something for X-XSS-Protection, send
0.
What to put your time into
| Instead of | Do this |
|---|---|
| X-XSS-Protection | A nonce or hash based CSP, output encoding, safe template defaults |
| Expect-CT | Certificate monitoring through CT logs, short renewal automation |
If a header is on your list because someone read an old checklist, check it against current MDN pages before spending time on it. For a current list, see which HTTP security headers to check and fix in a scan.
Try it yourself
Click through the web app scan to see how header findings are prioritised, and look at which ones carry real risk and which are advisory.
Click through it at your own pace, or open it full screen.
Quick check
Will removing X-XSS-Protection make my site less safe?
Not in modern browsers. MDN says a strong CSP makes the filter largely unnecessary, and the filter has caused vulnerabilities.
Is Expect-CT still used for certificate transparency?
No. Chromium deprecated it and enforces CT by default.
Safeguard's free scan covers dependencies and SBOMs, so you can focus header effort where it counts. Try it at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
