X-XSS-Protection is a HTTP header that enables built-in XSS filtering in some browsers. While modern browsers rely more on Content Security Policy, this header provides an additional layer of protection for older browsers. It can be configured to block or sanitize detected XSS attempts.
X-XSS-Protection is a legacy response header that controlled the built-in XSS auditor once shipped in Internet Explorer, Edge, and Chromium browsers. Values ranged from 0 (disable the filter), through 1 (enable and sanitise flagged content), to 1; mode=block (enable and block the whole page on detection). The filter tried to spot reflected scripts, code that appears in both the request and the response, and neutralise it before it executed. Modern browsers have removed this filter entirely: Chrome, Edge, and Safari no longer act on the header, and it never existed in Firefox. It is now considered obsolete, superseded by Content Security Policy.
The header mattered historically because it offered some reflected-XSS mitigation for browsers that predated a mature Content Security Policy. In practice the filters proved unreliable and, worse, introduced their own vulnerabilities: the sanitise mode could be abused to selectively disable legitimate scripts, and researchers found information-leak and universal-XSS side channels created by the auditor itself. That is why vendors deprecated and removed it. Today, sending 1; mode=block is at best inert and at worst re-enables buggy behaviour in an old browser. Current guidance recommends either omitting the header or explicitly sending 0, and relying on a strong CSP and output encoding instead.
Do not depend on X-XSS-Protection. Set it to 0 or leave it off, and put your effort into the controls that actually stop XSS today: context-aware output encoding, input validation, DOM sanitization for any HTML you insert, HttpOnly cookies so stolen tokens are harder to reach, and a strict, nonce-based Content Security Policy. Where XSS risk comes from third-party or injected JavaScript rather than your own templates, cside adds a complementary layer, routing third-party scripts through a Script method, analysing the payload, and blocking malicious behaviour in real time while keeping a forensic record, none of which the deprecated header ever provided.
No current browser acts on it; Chrome, Edge, and Safari removed the filter and Firefox never had it. Most guidance recommends omitting the header or sending 0, then relying on a strong Content Security Policy and output encoding. Sending 1; mode=block does nothing useful and can trigger old, buggy behaviour.
The auditors caught only simple reflected XSS while repeatedly creating new problems, including ways to disable specific scripts and universal cross-site-scripting or information-leak bugs. Fixing them reliably proved impractical, and Content Security Policy offered a far stronger, standardised alternative, so vendors chose to remove the filter altogether.
We answer client-side security questions every day. Bring yours.