For Developers‎ > ‎Design Documents‎ > ‎

XSS Auditor


The XSS Auditor runs during the HTML parsing phase and attempts to find reflections from the request to the response body. It does not attempt to mitigate Stored or DOM-based XSS attacks. 

If a possible reflection has been found, Chrome may ignore (neuter) the specific script, or it may block the page from loading with an ERR_BLOCKED_BY_XSS_AUDITOR error page.

The original design is the best place to start. The current rules are an evolved response to things observed in the wild.


Processing costs are essentially zero unless the URL or POST body includes any of the four characters " > < '. When those characters are found, we only invoke heavy processing on those attributes that might be dangerous. This stands in contrast to the XSS Filter in Internet Explorer, which runs costly regular expressions.

False Negatives (Bypasses and bugs)

Bypasses are not considered security bugs, but should be logged against the XSS Auditor component as functional issues.

False Positives

Unlike implementations in some other browsers, Chrome's XSS Auditor runs on same-origin navigations; this increases the risk of a false-positive but provides better protection against multi-stage attacks.

The XSS Auditor looks for reflected content within the context of executable (script) nodes. By checking for reflections only in contexts where script may be executed, the Auditor avoids many types of false positive. Because text that is reflected into a non-executable context (e.g. into a <textarea> element) does not trigger the Auditor. 

However, the Auditor has no way of knowing whether a given script block which appears in both the request and the response was truly reflected from the request to the response. For instance, consider this page that always contains the markup <script>alert("12345");</script>. If the user navigates to this page normally, the Auditor does not trigger. However, if the user navigates to this page using a URL whose query string contains ?query=<script>alert("12345");</script>, the Auditor concludes that the script appearing within the response page may be a reflection from the request (an XSS attack), and the XSS Auditor blocks the response.

In the past, the XSS Auditor defaulted to neutering only the potentially reflected block, leaving the rest of the page intact. However, this creates a vulnerability whereby an attacker may "snipe" an unwanted block of script from a victim page by sending the script to kill in the request body. To mitigate such attacks, as of Chrome 57, the XSS Auditor now blocks the response entirely. 

In some scenarios, a site legitimately wishes to send SCRIPT markup from one page to another where that markup may already appear (for instance, in the HTML Editing UI of a CMS or bulletin board site). In such cases, the site developers should either encode the content before transferring it (e.g. encode the content as base64, such that it is not identified as a reflection), or by opting out of the XSS Auditor by setting the HTTP response header.

Control via Response Header

Sites may control the XSS Auditor's behavior using the X-XSS-Protection response header, either disabling the feature or changing its mode. 

This Response header disables the Auditor:

      X-XSS-Protection: 0

This Response header enables the Auditor and sets the mode to neuter:

      X-XSS-Protection: 1

This Response header enables the Auditor and sets the mode to block (the default):

      X-XSS-Protection: 1; mode=block

Chrome's XSS Auditor allows the header to specify a report URI to which violation reports should be sent. That report URI must currently be same-origin to the page.

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

Debugging via View Source

If the XSS Auditor blocks or modifies a response because it detected reflected script, the View Source (CTRL+U) view for that page will point to the script that was reflected:

View-Source view highlights the reflected text


The code for the XSS Auditor feature can be found in Blink at XSSAuditor.h and XSSAuditorDelegate.hPerformance tests can be found here.


The XSS Auditor was introduced in Chrome 4 in 2010.