Correct. If the 3rd party js properly sanitizes user input, this xss attack is moot. However, browsers love to eval stuff (http://html5sec.org/), and sandbox iframes provide good defense in depth. Secure programs like qmail have been using separate, sandboxed processes forever, but this secure design model has only recently been possible in the browser thanks to iframes and postMessage (http://www.cs.berkeley.edu/~devdatta/papers/LeastPrivileges....).

The client obviously strips out any SCRIPT/HTML tags from the input but I guess your're talking about something more clever here. Can you provide an example attack that could potentially pass our security?

Thanks for responding. I would argue the opposite, that the browser is the safest place to sanitize because it better understands the context where user generated strings will be inserted.

An example where the server may not understand the correct context occurs in this utf7 attack (http://html5sec.org/#charset). The server sanitizes the user input as utf8 where it passes. The client forces the browser to interpret the input as utf7 instead, and the string that was harmless as utf8 now becomes active js.

Thank you for this good example. We'll study this one more closely.