The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. It’s usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
X-XSS-Protection: 0 turns it off.
X-XSS-Protection: 1 will filter out scripts that came from the request – but will still render the page
X-XSS-Protection: 1; mode=block when triggered, will block the whole page from being rendered.
Some Important Platforms and Implementation
Django SECURE_BROWSER_XSS_FILTER = True
Nginx add_header X-XSS-Protection “1; mode=block”;
Apache Header always set X-XSS-Protection “1; mode=block”
Learning from history, we know that no matter how hard the filter/auditor is improved, there are always potential bypasses. Besides, auditor also has its own limitations in certain contexts. So now there should be no argue that XSS filter/auditor is prone to bypasses, and its partial removal approach is problematic.
Logs :
http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf
https://bugs.chromium.org/p/chromium/issues/list?can=1&q=XSS+auditor[/ra_section_title]
