The X-XSS-Protection header recommendation is a Zombie recommendation which is at best outdated and at worst harmful. Its origins are based on old IE bugs but it introduces worse issues.<p>IMHO, the best value for X-XSS-Protection is either 0 (disabling it completely like Facebook does) or not providing the value at all and just letting the client browser use its default. Why?<p>First, XSS 'protection' is about to not be implemented by most browsers. Google has decide to deprecate Chrome's XSS Auditor[0], and stop supporting XSS 'protection'. Microsoft has already removed its XSS filter from Edge[1]. Mozilla has never bothered to support it in Firefox.<p>So most leading net companies already think it doesn't work. Safari of course supports the much stronger CSP. So it's only possibly useful on IE - if you don't support IE, might as well save the bytes.<p>Second, XSS 'protection' protects less than one might think. In all implementing browsers, it has always been implemented as part of the HTML parser, making it useless against DOM-based attacks (and strictly inferior to CSP)[2].<p>Worse, the XSS 'protection' can be used to <i>create</i> security flaws. IE's default is to detect XSS and try to filter it out, this has been known to be buggy to the point of creating XSS on safe pages[3], which is why the typical recommendation has been the block behaviour. But blocking has been itself exploited in the past[4], and has side-channel leaks that even Google considers too difficult to catch[0] to the point of preferring to remove XSS 'protection' altogether. Blocking has an obvious social exploitation which can create attacks or make attacks more serious.[5]<p>In short, the best idea is to get rid of browsers' XSS 'protection' ASAP in favour of CSP, preferably by having all browsers deprecate it. This is happening anyway, so might as well save the bytes. But if you do provide the header, I suggest disable XSS 'protection' altogether.<p>[0] <a href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ" rel="nofollow">https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...</a><p>[1] <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/17723/" rel="nofollow">https://developer.microsoft.com/en-us/microsoft-edge/platfor...</a><p>[2] e.g. <a href="https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1ff5bf1a901765e47923/Source/WebCore/html/parser/XSSAuditor.cpp" rel="nofollow">https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1f...</a><p>[3] CVE-2014-6328, CVE-2015-6164, CVE-2016-3212..<p>[4] <a href="https://portswigger.net/blog/abusing-chromes-xss-auditor-to-steal-tokens" rel="nofollow">https://portswigger.net/blog/abusing-chromes-xss-auditor-to-...</a><p>[5] Assume that an attacker has enough access to normally allow XSS. If he does not, the filter is useless. If he does, the attacker can by definition trigger the filter. So trigger the filter, make a webpage be blocked, and call the affected user as "support". From there the exploitation is obvious, and can be much worse than mere XSS. Now, remember that all those XSS filters in all likelihood have false positives, that may not be blocked by other defences because they're not attacks. So It's quite possible the filter introduces a social attack that wouldn't be possible otherwise!<p>Hattip: <a href="https://frederik-braun.com/xssauditor-bad.html" rel="nofollow">https://frederik-braun.com/xssauditor-bad.html</a> which gave me even more reasons to think browsers' XSS 'protection' is awful. I didn't know about [2] before reading his entry.