XSS Protection Headers: What Still Works in 2026

For years, the X-XSS-Protection header was a staple recommendation in every security checklist. In 2026, the story is more nuanced: the browser-based XSS Auditor that this header controlled has been removed from all major browsers, and the header itself can in some edge cases introduce vulnerabilities rather than prevent them.

This article explains the history of XSS protection headers, what happened to the XSS Auditor, and what you should use instead. It is part of our complete guide to HTTP security headers.

A Brief History of X-XSS-Protection

The X-XSS-Protection header was introduced by Internet Explorer 8 in 2008 and later adopted by Chrome and Safari. It controlled a built-in browser feature called the XSS Auditor, which attempted to detect reflected XSS attacks by comparing URL parameters to the rendered page content. If it detected a match, it could either sanitize the suspicious content or block the page entirely.

The header accepted these values:

• X-XSS-Protection: 0 — disable the auditor.
• X-XSS-Protection: 1 — enable the auditor (sanitize mode).
• X-XSS-Protection: 1; mode=block — enable the auditor and block the entire page if an attack is detected.
• X-XSS-Protection: 1; report=<url> — enable the auditor and send a report.

Why the XSS Auditor Was Removed

Security researchers discovered multiple problems with the XSS Auditor:

• Bypass after bypass. Researchers continuously found ways to craft XSS payloads that the auditor did not detect. It could never achieve comprehensive coverage.
• False positives causing information leaks. An attacker could craft a URL that made the auditor block legitimate scripts on the target page, selectively disabling security features or exposing side-channel information.
• Sanitization-mode vulnerabilities. In sanitize mode (the default), the auditor removed suspicious content from the page, which sometimes altered the DOM in ways that created new XSS vectors that did not previously exist.

Chrome removed its XSS Auditor in version 78 (October 2019). Edge followed when it switched to Chromium. Firefox never implemented one.

What Should You Set in 2026?

The recommended value is:

X-XSS-Protection: 0

This explicitly disables the auditor in any legacy browser that might still have it. Setting it to 1 in 2026 has no benefit in modern browsers and could theoretically cause issues in edge cases with very old browsers.

Some teams choose to omit the header entirely, which is also acceptable since modern browsers do not have an auditor to control.

What Actually Prevents XSS in 2026

The death of the XSS Auditor does not mean browsers cannot help prevent XSS. The successor is Content Security Policy, which is far more powerful and reliable:

• Block inline scripts by not including 'unsafe-inline' in script-src. This single directive prevents the vast majority of reflected and stored XSS attacks.
• Use nonces to allow specific inline scripts: script-src 'nonce-random123'. An attacker cannot guess the nonce, so injected scripts are blocked. See our CSP deep dive for details.
• Use 'strict-dynamic' to let trusted scripts load additional scripts without whitelisting every CDN.
• Block eval() by omitting 'unsafe-eval' from script-src.

A Modern Anti-XSS Header Set

Here is the recommended set of headers for XSS prevention in 2026:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'
X-Content-Type-Options: nosniff
X-XSS-Protection: 0

The CSP does the heavy lifting. X-Content-Type-Options: nosniff prevents MIME sniffing attacks that could bypass the CSP. And X-XSS-Protection: 0 ensures no legacy auditor interferes.

Testing

Use our XSS protection test tool to check your current header configuration. For a comprehensive check of all security headers, use the security headers audit. Also test your CSP separately to ensure it provides effective XSS mitigation.

For the complete picture of all security headers you should configure, return to our security headers guide.