X-XSS-Protection allows developers to change the behavior of the Reflected XSS (Cross-Site Scripting) security filters. These filters aim to detect dangerous HTML input and either prevent the site from loading or remove potentially malicious scripts.

What Can Malicious Attackers Do When Exploiting a Reflected XSS Vulnerability?

Reflected XSS is a vulnerability that arises from the evaluation of user input as script code in the page context.

Malicious actions – such as stealing users’ cookies, tracking keyboard strokes or mouse moves, or issuing requests on behalf of the user – can all be carried out with the help of XSS. This is how it works. Consider the following PHP code:

<p>Welcome <?php echo $_GET["name"];?></p>

By passing the following HTML and JavaScript code to the name parameter, the application will embed it unfiltered on the page, which will display a JavaScript alert window on the vulnerable website.

http://www.example.com?name=<script>alert(1);</script>

The Different X-XSS-Protection Header Directives

It is possible to change the behavior of the XSS filter in the web browser by using various directives. In this section we explain what the different directives are and what their purpose is.

X-XSS-Protection: 1

This is the default setting. It enables XSS filtering on the web browser and blocks out potential XSS payloads from being executed on the page.

X-XSS-Protection: 1; mode=block;

This enables XSS filtering in the browser. It avoids potential execution of XSS payloads by blocking the rendering of the page. When the XSS payload is deployed, the visitor gets a blank page on the browser.

In Chromium based browsers, the XSS injection attempt can be reported to the URL specified in the report directive.

X-XSS-Protection: 1; mode=block; report=https://domain.tld/folder/file.ext

The XSS filter is responsible for the detection of reflected script code. It is triggered if potentially malicious HTML code is found in both the request and response on the HTML page. While some directives will instruct the browser to remove the malicious script in question, others prevent the rendering of the page entirely.

For example:

Request URL:

http://www.example.com/?param=<script>alert(1);</script>

Response body:

…
<div>
<script>alert(1);</script>
&lt;/div>

However, XSS filters have been abused in the past in order to to block the rendering of parts of an HTML page. Attackers can take advantage of the default behavior of XSS filters that block any potentially dangerous code if it occurs within the URL of the page.

Bypassing the XSS Blocking Mechanism

XSS filters are also used by attackers to disable important HTML and JavaScript code, for example, Frame Busting mechanisms. Recent years have shown that innovative techniques have been developed that can deactivate scripts or steal user data with the help of these filters.

Let’s look at an example of a Frame Busting mechanism. If the developer figures out that the website was loaded within a frame, they can redirect the top window to their website using this code:

<script>
if(top != self) {
  top.location = self.location;
}
</script>

The attacker can bypass this using the X-XSS-Protection mechanism that is active by default:

<iframe src="http://www.victim.com/?v=<script>if">

Instead of blocking a Cross-Site Scripting attack, sometimes X-XSS-Protection: 1; (a default setting in Internet Explorer) has been used to bypass the XSS blocking mechanisms. Those vulnerabilities were fixed, but it shows that every feature you add to a browser can threaten the security of end users, even those intended to enhance their security.

Researchers argue that the Content-Security-Policy headers in modern browsers are sufficient to ensure mechanisms like X-XSS-Protection are no longer necessary. Others, however, have suggested that the feature is not secure enough and doesn’t add much value (see the discussion on Bugzilla).