Note: An Intent to Deprecate and Remove the XSS Auditor was published on 15-July-2019. The feature was permanently disabled on 5-August-2019 and shortly after fully removed for Chrome 78.
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 http://www.collinjackson.com/research/xssauditor.pdf 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.
same-origin navigations; this increases the risk of a false-positive but provides better protection against multi-stage attacks.
(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.
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.
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.
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.
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:
This Response header enables the Auditor and sets the mode to neuter:
This Response header enables the Auditor and sets the mode to block (the default):
X-XSS-Protection: 1; mode=block
When the feature is enabled (state "1"), Chrome's XSS Auditor allows the header to specify a report URI to which violation reports should be sent. In Chrome 64 and 65, that URI must be same-origin to the page, but that limit was removed in Chrome 66. If your report URL includes a semicolon, be sure to wrap the URL in quotation marks.
X-XSS-Protection: 1; mode=block; report=https://example.com/log.cgi
X-XSS-Protection: 1; report="https://example.com/log.cgi?jsessionid=132;abc"
reflected script, the View Source (CTRL+U) view for that page will point to the script that was reflected:
The XSS Auditor was introduced in Chrome 4 in 2010.
The XSS Auditor works by matching request data to data in a response page, which may be cross-origin. This creates the possibility that the XSS Auditor may be abused by an attacker to determine the content of a cross-origin page, a violation of Same Origin Policy.
In a canonical attack, the attacker frames a victim page with a string of interest in it, then attempts to determine that string by making a series of successive guesses until it detects blocking by the XSS Auditor. If the XSS Auditor blocks the page, the attacker concludes that their guess was correct. This form of attack is constrained to pages matching certain criteria.
To combat this threat, the attacker should not be able to detect that the Auditor has blocked loading of the page. Most known detection mechanisms have been fixed, although a website with a content injection vulnerability may remain vulnerable and quirks of same-origin-policy may permit detection of blocking.