HTTP Headers

X XSS Protection

HTTP Header

Non-standard: This feature is considered non-standard and is not part of any formal standards track. It is not recommended to use it on production websites, as it may not work consistently for all users. There might be significant differences between implementations, and its behavior could change in the future.

Deprecated: This feature is no longer advised for use. While some browsers may still support it, it has likely been removed from official web standards, is in the process of being phased out, or is retained solely for backward compatibility. Developers should avoid using it and update existing code where possible. Refer to the compatibility table at the bottom of this page to assist with decision-making. Note that this feature might stop functioning at any time.

Warning:
Although this feature can help protect users of older browsers that do not support CSP, it can sometimes introduce security vulnerabilities, such as X-XSS-Protection creating XSS issues in otherwise secure websites.
For more details, see the Security considerations section below.

The HTTP X-XSS-Protection response header was a feature supported by Internet Explorer, Chrome, and Safari that aimed to prevent the page from loading when reflected cross-site scripting (XSS) attacks were detected.
In modern browsers, these protections are largely redundant when websites implement a robust <code>Content-Security-Policy</code> that disables inline JavaScript execution ('unsafe-inline').

It is recommended to prioritize Content-Security-Policy over XSS filtering to enhance security.

Header type	Response header
Forbidden request header	No

Syntax

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=&lt;reporting-uri&gt;

Directives

0

Disables Cross-Site Scripting (XSS) filtering.

1

Enables XSS filtering, which is usually enabled by default in browsers. If a cross-site scripting attack is detected, the browser will sanitize the page by removing the unsafe parts to protect the user.

1; mode=block

This directive enables XSS filtering and takes a stricter approach by preventing the rendering of the entire page if an attack is detected, rather than just sanitizing parts of it.

1; report=<reporting-URI> (Chromium only)

Enables XSS filtering. If an attack is detected, the browser will sanitize the page and send a report of the violation to the specified reporting URI using the Content Security Policy report-uri directive. This allows for monitoring and analysis of potential threats.

Example

Security considerations

Vulnerabilities caused by XSS filtering

Consider the following excerpt of HTML code for a webpage:

html

<script>
 var productionMode = true;
</script>
<!-- [...] -->
<script>
 if (!window.productionMode) {
 // Some vulnerable debug code
 }
</script>

This code is completely safe if the browser doesn’t perform XSS filtering. However, if it does and the search query is ?something=%3Cscript%3Evar%20productionMode%20%3D%20true%3B%3C%2Fscript%3E, the browser might execute the scripts in the page ignoring <script>var productionMode = true;</script> (thinking the server included it in the response because it was in the URI), causing window.productionMode to be evaluated to undefined and executing the unsafe debug code.

Setting the X-XSS-Protection header to either 0 or 1; mode=block prevents vulnerabilities like the one described above. The former would make the browser run all scripts and the latter would prevent the page from being processed at all (though this approach might be vulnerable to side-channel attacks if the website is embeddable in an <iframe>).

Example

Block pages from loading when they detect reflected XSS attacks:

http

X-XSS-Protection: 1; mode=block

PHP

php

header("X-XSS-Protection: 1; mode=block");

Apache (.htaccess)

apacheconf

<IfModule mod_headers.c>
 Header set X-XSS-Protection "1; mode=block"
</IfModule>

Nginx

nginx

add_header "X-XSS-Protection" "1; mode=block";

Specifications

Not part of any specifications or drafts.

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the X-XSS-Protection header. This is especially useful for testing how your application handles cross-site scripting protection settings during development or debugging. Steps to Modify the X-XSS-Protection Header:

Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter X-XSS-Protection.
- In the “Header Value” field, enter the desired value (e.g., 1; mode=block or 0).
Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-website.com/*).
Save the rule.

Once set up, Requestly will inject the specified X-XSS-Protection header into all matching requests, letting you test how different XSS protection settings affect your website’s security and behavior. Modifying the X-XSS-Protection header can help you test if your web application properly blocks or reports cross-site scripting attacks. It allows developers to verify security configurations and ensure that browsers apply the intended XSS protection mechanisms.