X-XSS-Protection Header Missing: What to Do in 2026

What X-XSS-Protection was

X-XSS-Protection is an HTTP response header that older browsers used to control a built-in "XSS filter," sometimes called the XSS Auditor. The idea was simple on paper: the browser compared the URL and request parameters against the content of the page it received, and if a chunk of script in the response looked like it had been reflected straight from the request, the browser assumed a reflected cross-site scripting (XSS) attack and either stripped the suspicious content or refused to render the page at all.

For years the common recommendation was to send X-XSS-Protection: 1; mode=block, which told the browser to enable the filter and block the whole page when it detected something suspicious. Security checklists, hardening guides, and audit tools all picked this up, which is exactly why so many of them still report it as "missing" today.

Why it is now deprecated

The header is officially deprecated and the underlying filter has been removed from every major browser. Microsoft Edge dropped its XSS filter in 2018, Chrome removed its XSS Auditor in version 78 (October 2019), Safari removed its equivalent in 2022, and Firefox never implemented one at all. Per MDN, the feature is non-standard and should not be relied upon.

The reason browser vendors walked away from it is that the filter caused more problems than it solved. It worked by pattern matching, so attackers found many ways around it using character encoding tricks, HTML entity abuse, and DOM-based injection that the heuristic never saw. Worse, the filter could be turned into a weapon: a crafted URL could trick the auditor into selectively disabling legitimate scripts on a page, and in sanitize mode the act of stripping "suspicious" content sometimes mutated the DOM in ways that created brand new XSS vectors that did not exist before. A defense that an attacker can use to break your own page is not a defense worth keeping.

Why auditors still flag it

Many crawlers and security scanners, including Screaming Frog, Sitebulb, and various header checkers, still list "X-XSS-Protection Header Missing" as an issue. These rules were written when the header was best practice and many simply have not been retired. Seeing this flag does not mean your site is vulnerable, and in most cases it does not even mean you should add the header back. It means a scanner ran a check against an old expectation. The correct response is to understand what real protection you have in place rather than blindly satisfying the rule.

The modern fix: Content-Security-Policy

The genuine replacement for the old XSS filter is a Content-Security-Policy (CSP) header. Both OWASP and MDN recommend using CSP instead of XSS filtering. A well-built CSP restricts where scripts can load from and blocks inline script execution, which stops both reflected and stored XSS far more reliably than any browser heuristic ever could, because it controls what is allowed to run rather than guessing what looks malicious.

A simple starting policy looks like this. Test it carefully, because a strict policy can break inline scripts and third-party widgets until you account for them:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

Deploying CSP well takes iteration. Start in report-only mode (Content-Security-Policy-Report-Only) so you can see what would be blocked without breaking the live site, review the reports, then enforce. That work is what actually closes the gap the old header pretended to cover.

If you still want to set the header

Sometimes a client, a compliance checklist, or a scanner simply insists on a value. In that case, the value the security community now recommends for modern sites is 0, which explicitly disables the defunct filter and avoids the page-mutation risks that came with 1; mode=block:

X-XSS-Protection: 0

You may still see X-XSS-Protection: 1; mode=block recommended in older guides. It is harmless on browsers that ignore it, but it offers no real protection and historically introduced subtle risks, so 0 (or simply not sending the header and relying on CSP) is the cleaner choice.

How to diagnose

Check what your server currently sends with a single request and look at the response headers:

curl -sI https://example.com | grep -i -E 'x-xss-protection|content-security-policy'

You can also open your browser developer tools, go to the Network tab, reload the page, click the main document request, and read the Response Headers. If you see no Content-Security-Policy line, that is the gap worth your attention, not the missing X-XSS-Protection line.

How to fix

Apache

Add this to your .htaccess or virtual host config with mod_headers enabled:

<IfModule mod_headers.c>
    Header set X-XSS-Protection "0"
    Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'"
</IfModule>

Nginx

Add this inside the relevant server block, then reload Nginx:

add_header X-XSS-Protection "0" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;

WordPress

If you cannot edit server config, send the headers from your theme's functions.php or a small plugin:

add_action('send_headers', function () {
    header('X-XSS-Protection: 0');
    header("Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'");
});

Many security plugins such as Really Simple Security or Wordfence can also manage these headers from a settings panel if you prefer not to touch code. Whichever route you take, build and test your CSP first, since that is the control doing the real work.

FAQ