With the introduction of the HTTP X-XSS-Protection header it seems to me that the vulnerability impact (read: amount of possibly affected users with modern browsers) is drastically reduced.

Firstly, does this mean that when the X-XSS-Protection header is properly set and that when the browser's XSS protection is enabled, the web developers don't need to worry about XSS anymore (at least for the visitors with modern browsers)? Which could be as simple as "We don't support browsers X, X and X and versions X and lower.".

Secondly, what (popular) browsers implemented this security feature, is it enabled by default, and since what version or on what date was that version released?

Thirdly, are there known bypasses of that browser's XSS filter?

  • 8
    Browser XSS filters don't protect against stored XSS. There have been various bypasses as well, like this. While the bypasses tend to get fixed, the general reckoning is that a determined attacker can still get past them.
    – paj28
    Jun 25, 2016 at 16:49
  • 1
    X-XSS-Protection will not end-of-life XSS, however Content Security Policy has the power to do this, should it be properly configured. It will not end-of-life it's cousin HTML injection though, although it can severely restrict the impact. Jun 27, 2016 at 15:58

3 Answers 3


Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header?

No. X-XSS-Protection is only used to enable or disable the inbuilt filtering[*] - which is generally enabled by default anyways.

So a more fitting question would be if XSS reached its end-of-life with browser filters.

But again, the answer is no. XSS is still a danger, because of three reasons:

  • Persistent XSS is not affected by browser filtering at all, as the browser has no way of knowing what is user input and what isn't.
  • Some browsers do not have filters against XSS, for example Firefox. XSS vulnerabilities are introduced server-side and web developers should not rely on browser vendors defending against them.
  • Bypassing of browser filters: XSS is context sensitive, which makes it very difficult to defend against without knowing the context (which is also why XSS should be defended when outputting data, not via some generic input filter).

The bypassing can basically happen because of two reasons:

  1. There is a bug in the filter.
  2. The user input is echoed in a location where filtering is not practical. One example would be <script>[userinput]</script>.

[*] As the header is not defined in any RFC, it is difficult to say how browsers will react. For example, Chrome 51 will disable its filter if the header is set to 0, but it will not re-enable the filter in case the user disabled it if 1 is set. Other browsers may behave different.

Which could be as simple as "We don't support browsers X, X and X and versions X and lower.".

It's really not that simple. Especially large organizations are notoriously bad at updating. Depending on your website, you can't just say that you don't support browsers X.

Secondly, what (popular) browsers implemented this security feature, is it enabled by default, and since what version or on what date was that version released?

X-XSS-Protection is supported by IE, Chrome, and Safari.

Chrome had an XSS filter since 2010 (Chrome 4). It was disabled by default in the same year, and then re-enabled in Chrome 8.

IE had an XSS filter since 2008 (IE 8).

Firefox doesn't have a filter, the NoScript plugin does though.

Thirdly, are there known bypasses of that browsers XSS filter?

Yes. Of course. There are more. Most depend on some specific situation (eg input is echoed in two locations). The IE8 filter actually introduced an XSS vulnerablity, even into sites that did not contain one.

  • 1
    To add to this- besides using simple and ineffective blacklisting, the web browser has no way to identify malicious, XSS-causing JavaScript versus JavaScript that is intended to be a part of the website. Jun 25, 2016 at 18:56
  • 1
    Are you sure X-XSS-Protection: 1 will enable the filter if disabled by the user? Also you could add that 1; mode=block offers better protection because it prevents the whole page being rendered should a reflective XSS attack be detected, and this would also mitigate attacks like the one with the IE8 filter because nothing will be rendered if this is attempted. Jun 27, 2016 at 15:55
  • @SilverlightFox Thanks for the question and comment regarding block mode. Based on everything I read, it should re-enable the filter. But I tried it with Chrome 51, and it did not work (0 does disable the filter though), I can't test IE right now.
    – tim
    Jun 27, 2016 at 16:42

Actually, even if that header could solve the problem, the second part is a human factor: the hosters/developers/webmasters are about to use it, actually...


At the time of this writing:

Not only did browser filtering fail to stop XSS, but XSS killed browser filtering!

The XSS Auditor (controlled by the X-XSS-PROTECTION header) in all its forms is officially dead. In general, it died because it's goals were simply not realistic. Protecting against even just reflected XSS from the browser-level is just not as easy as you might think. The XSS Auditors were subjects of frequent bypasses and also caused false positives. They even allowed for cross-site data leaks that were impossible to plug (summary here). In the end, the benefit wasn't worth the effort. The Mozilla page on the X-XSS-PROTECTION header gives the current status:

  • Chrome has removed their XSS Auditor
  • Firefox has not, and will not implement X-XSS-Protection
  • Edge has retired their XSS filter

It was available in Chrome from versions 4-78, Edge in 12-17, and in Firefox never.

XSS will live for as long as HTML and JavaScript do.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .