Is Chrome completely secure against Reflected XSS?

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:

?q=<script>alert("XSS!")</script>

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:

?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+

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

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

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:

eval(location.hash.substring(1))

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.

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