X-XSS-Protection

This test checks for the presence of the X-XSS-Protection Header with a value of "0". The purpose of this header is to cause the web browser to sanitize or block the loading of a page if it detects a reflected cross-site scripting (XSS) attack. In the past, it was good to enable this header, but with modern web browsers it can cause more harm than good. The current recommendation is to turn this header off to prevent unwanted effects. Instead, you should have a properly configured Content-Security-Policy.

Reflected XSS Attacks

A reflected XSS attack can happen if a website takes unsanitized user input and displays it on the page where another user could see it. For example, a website's URL may contain parameters such as www.example.com?search=socks, and then on the page it may show a search bar with "socks" reflected in the input box. If the website has not taken care to sanitize the value of the "search" parameter then an attacker could put malicious code in here and trick someone into loading the malicious URL. In this example, www.example.com?search=<script> ... </script> would cause the page to run any code that the attacker wants. This code can view any information and perform any action that the user could perform on their own, so it is very dangerous.

Protection

When the "X-XSS-Protection" header is set, and the browser detects executable code in the URL, it will automatically sanitize the webpage and prevent the attack from happening. Enabling this protection using this header can allow hackers to disable parts of your website by sharing maliciously crafted links to your website. This header works for Safari as well as some older web browsers but has been removed from Chrome. Or recommendation is to disable this header so it wont work in Safari, and instead use a CSP header which is more powerful. For more information about the possible values for this header, please read our documentation for the X-XSS-Protection Header.

Stored XSS Attacks

A Stored XSS attack is a similar sort of attack. The difference being that the malicious code is stored by the website instead of being inserted into the URL. For example, it could be a bit of JavaScript code added to a comment or review posted by a user. When someone else views that comment, the code could get executed. The X-XSS-Protection header does not protect against this type of attack, but the newer Content-Security-Policy (CSP) header protects against both.

To learn more about this header and other security headers, please read our in-depth article on HTTP Headers That Protect Your Users.