Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In Firefox I've been using the NoScript extension to protect myself from certain kinds of malware attacks. NoScript is well known as a very powerful extension for Firefox and introduced protection from XSS and clickjacking attacks as far back as '07.

I've been looking for similar protection in Chrome, but the best I found was ScriptNo which does not specifically mention such a kind of protection (it only mentions Cross-Domain XML).

Does Google Chrome protect against cross site scripting (XSS)? (e.g. Is this passively achieved via sandboxing?)

share|improve this question

Chrome has default protection against Reflective XSS attacks. This is not a flaw that sandboxing can address. This protection system works by looking outgoing requests for javascript and preventing that javascript from being executed in the http response. No browser will prevent DOM Based XSS or Stored XSS.

Chrome's protection is the weakest when compared to the others. IE's xss filter isn't very good, but slightly better than Chrome's. From my research I think the NoScript is by far the best. I have bypassed NoScript's XSS filter by exploiting content insensitivity, and they fixed the issue quickly. Chrome and IE still suffer from content insensitivity attacks.

Microsoft says that content insensitivity attacks against IE are "not a vulnerability" and they will never fix these issues. Chrome has had a bug report open for this issue and I haven't seen activity for about 6 months. So chrome might fix it eventually, maybe. Which to be honest both of these are horrible vendor responses. In general I find that NoScript and Mozilla have the strongest responses to vulnerabilities in their software and as a security researcher they are a joy to work with!

share|improve this answer
Thanks for your informative input! Why do you think that even the Chrome team responds so slowly here? Is it because the focus is on protecting the computer and not the user information that is handled on a website? E.g. I could follow the IE statement "not a vulnerability" by saying that the fix should be provided by the website administrator. Still, I understand that this statement shows carelessness. – user10356 Jun 19 '12 at 20:31
@gentmatt I'm not sure to be honest. I think the chrome team has a lot on their hands and they are more concerned with just having a feature that says "protects against reflective xss" instead of making a really solid security feature. Microsoft on the other hand is just notorious for leaving vulnerabilities unpatched. A good example is the IE "drag-and-drop" vulnerability which was a remote code execution vulnerability left unpatched for almost two years. I hate IE so much. – rook Jun 19 '12 at 20:44
I would say it's because there is no way to make a 'perfect' XSS filter. There will always be ways to sneak content past a client-side filter that will cause a buggy server-side application to fail. The problem's in the server not the client, so you can't fix it there; the client-side XSS filter is a defence in depth measure that can't ever be watertight. By "fixing" it you would necessarily be adding to its false positives. – bobince Jun 20 '12 at 8:07
Personally I consider client-side XSS filtering to be a deeply mistaken idea, that only ever worked, for NoScript users, through obscurity: as long as there weren't too many users with NoScript, it could target the most common attacks and have some success. As soon as you build the filtering into a popular browser (ie: IE), it loses its effectiveness, as the attacks work around the filter. – bobince Jun 20 '12 at 8:09
@bobince I think that they are effective to some extent, and they aren't going away. You should try exploiting an XSS flaw with a browser that has a filter, it is not trivial. – rook Jun 20 '12 at 15:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.