I notice that Chrome does not execute scrips that are part of the web request,


With such links since the script is as part of the web request, Chrome does not execute the script. Does that prevent all kinds of Reflected XSS attacks with Chrome browser ?

Edit: I've already read this thread; although the title seems similar, the contents are different.


No, because the XSS filter only looks whether it sees XSS code in the input back in the HTML outputted by your server.

For example, if Chrome sees your web page is accessed with an URL that contains the following:


and if the HTML returned by the server contains this:

<p>You have searched for <b><script>alert("XSS!")</script>

it knows that this code is most likely the result of it being included in the request, and neutralizes it.

However, if the code is not found in the request, for example if the application accepts input that is encoded in some way, the filter may not be able to figure out that the code is the result of some XSS code embedded in the request.

As seen in the commit log for WebKit, until it was forked recently the rendering engine in Chrome, they are trying to address the most common bypasses, where the XSS-code in the URL and the resulting XSS-code in the HTML look slightly different.

If none of these rules for special cases apply, the XSS will be left through. For example, if they aren't decoding Base64-encoded data in the URL, if the web application were to accept input encoded with Base64, it may be possible to XSS a web application.

An example:


(PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+ is <script>alert("XSS!")</script> encoded in Base-64), if not filtered, would result in response HTML like this:


Additionally, it won't stop XSS occurring with data that is not embedded in the HTML unencoded, but is treated in an unsafe way by JavaScript.

For example, consider a page which contains the following JavaScript:


This will execute any code trailing the # in the URL, but it is not filtered out by Chrome.

You can see this example in action here

Another example, which uses Base64


XSS prevention is not the responsibility of the browser, XSS holes arise because of flaws in a website, and it is up to the owners of websites to prevent such flaws.

Some browsers have implemented attempts at mitigating XSS and CSRF holes in websites, but these are heuristics looking for typical patterns of attacks. They are in no way complete.

There is infinitely many ways to implement an XSS hole, and there is no sure way of distinguishing between a hole and intended behaviour. There is no way a browser filter can ever be a replacement for site owners knowing about, caring about, and addressing the issue of XSS and CSRF holes.

I do wonder if these filters do more harm than good by creating a false sense of security.

  • 1
    Any examples would be great ... – vikkyhacks Mar 17 '14 at 5:48
  • 1
    +1 Sometimes XSS filters can be used against a website. e.g. adding ?<script>... to the URL where ... is some code you want filtered from the page output. – SilverlightFox Mar 17 '14 at 11:43
  • 2
    @vikkyhacks Take the W3Schools tryit editor for instance, it is basically a completely raw reflected XSS implementation, though it is intended behaviour, and a nice feature. But then again, it does actually allow one to forge a request that does whatever the hell one wants on thier domain, including pushing malware. (The W3Schools folks could and should make a token system that prevents code not being input through the form from being echoed.) The browser filters don't catch it for some reason, and whether or not they should is an open question. – aaaaaaaaaaaa Mar 17 '14 at 18:54

Nope. See this Webkit commit and find the word "bypass". You will see Auditor bypasses that researchers have found over the period of time ...


As noted on Chrome bug 118808 by a developer:

XSS auditor bypasses don't constitute Chrome security vulnerabilities (which is why this bug is flagged SecSeverity-None). You can find our severity guidelines here: http://dev.chromium.org/developers/severity-guidelines

To clarify a bit more, the XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can't catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.

which shows how the Chrome team itself doesn't expect it to be completely secure (which is probably impossible).


The Chrome XSS Auditor can be bypassed using the following scripts:

  1. http://vulnerable_site?pageTitle=<a href="data:text/html,your xss payload">xss

  2. http://vulnerable_site?pageTitle=<a href="data:text/html;base64,base 64 encoded format of your xss payload">xss

  • Those wouldn't execute in the context of the page, and so wouldn't actually constitute an XSS vulnerability, would they? (edit: see this bug -- it looks like this approach might work in Firefox, but not in Chrome, as is being discussed.) – Jeremy Banks Apr 18 '16 at 20:50

chrome protects against all known reflected xss attack vectors. If you could find a way around this filter, goog will give you a bounty. That said, reflected xss is still a vulnerability on the website

  • 1
    @Totmaxx any link to support this answer would be great ? – vikkyhacks Mar 17 '14 at 5:48
  • 1
    "chrome protects against all known reflected xss attack vectors" - not true at all – George Powell Sep 28 '15 at 10:21
  • Do you have a reference that there will be a bounty for XSS auditor bypasses? At least in the past it wasn't considered a security vulnerability. See bugs.chromium.org/p/chromium/issues/detail?id=118808#c10 – Ángel Jul 14 '18 at 21:03

protected by Anders Feb 5 '18 at 15:35


Would you like to answer one of these unanswered questions instead?
