Microsoft recently announced that they were going to remove the XSS Filter from their Edge browser. I have some mixed feelings about this so I'm going to go through them here and gather some feedback from others in the community too.


The XSS Filter

XSS mitigations were first built into IE 8 back in July 2008! In a blog post titled IE8 Security Part IV: The XSS Filter there was talk of how XSS attacks were skyrocketing and how the browser was going to help with that.


When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.


This sounds like a great starting point for having the browser help protect against XSS attacks and the post is even open and realistic about the capabilities of the filter.


Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea.


The announcement

In their blog post Announcing Windows 10 Insider Preview Build 17723 and Build 18204 there are several updates covered but of course we're interested in the section on Microsoft Edge, specifically the "Retired XSS Filter" section.


Retired XSS Filter: We are retiring the XSS filter in Microsoft Edge beginning in today’s build. Our customers remain protected thanks to modern standards like Content Security Policy, which provide more powerful, performant, and secure mechanisms to protect against content injection attacks, with high compatibility across modern browsers.


Now, there are a couple of problems with this statement so let me outline them and give my reasons for concern.


CSP adoption

I think my thoughts on this particular problem can be summarised quite nicely by my tweet.



From the Microsoft article linked above, they say the following about CSP.


Our customers remain protected thanks to modern standards like Content Security Policy, which provide more powerful, performant, and secure mechanisms to protect against content injection attacks, with high compatibility across modern browsers.


Now, it is true that can CSP can offer protection against XSS, this is after all one of the main reasons it was invented, but there's a problem with that. The site has to deploy CSP, and deploy it properly, for visitors to have any protection against XSS. The first issue there is that the current adoption for CSP in the top 1 million sites on the web is less than 4%... We're going from 100% of Edge users having protection against some XSS attacks thanks to the filter down to (at most) <4% having protection against those same XSS thanks to CSP. The other problem with that number is that not all of the sites are using CSP to defend against XSS. CSP has a great many uses and a popular one right now is fixing mixed content. I've covered this use in my blogs Fixing mixed content with CSP and Migrating from HTTP to HTTPS? Ease the pain with CSP and HSTS!. CSP is great for these purposes so just because a site is using CSP, it doesn't mean they're using it for XSS protection so even fewer people will be protected against XSS now. Whilst Microsoft are right in saying that CSP support is widespread, CSP deployment is not!


CSP is a defense-in-depth mechanism

Don't believe me? It even says so in the RFC.


Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks. As a first line of defense against content injection, server operators should validate their input and encode their output.


As part of a defense-in-depth strategy it doesn't make sense to remove the filter and claim that CSP will take care of XSS because we're supposed to have multiple layers of defense, and now we're removing one because of the other. Yes, of course we should validate input and encode output, but as we all know, many applications do not. Even when/if we do, mistakes are made which is why we need CSP in the first place, to catch things that slip through the net. The XSS Filter was a great last line of defense that is present in the browser and was essentially our last hope of stopping an attack.


The XSS Filter isn't perfect

I want to clear up a couple of innevitable points that will be raised to save us all a little time later on. No, the XSS Filter is not perfect, but that's not a reason to not have one. Let's cover some of the problems with the filter.

The XSS Filter can only help protect us against reflected XSS attacks so that is a limited subset of the possible XSS related issues we're going to face. Still though, it's best to have the browser on our side and trying to help us stop some attacks instead of no attacks at all.

The XSS Filter can't stop all reflected XSS attacks, it's true. The filter isn't perfect and it isn't going to detect and stop all attacks, that was outlined in the original post to announce the filter as I quoted at the start. But again, that's not a reason to get rid of it. If the filter can stop even 10% of attacks then that's a lot more attacks than it will stop if it's not there.

The XSS filter can be tricked. I have shown a demo for this a couple of times myself and there are documented cases of this online too. The filter can be tricked into taking action when it shouldn't by making something look like an attack when it isn't, with differing results based on your objective. The main point here is that yes this is possible but it's rare, very rare. For the vast majority of the time the filter is helping us and saving us but every now and then it will let us down. It's still doing a lot more good than harm.


Why is the filter being removed?

Honestly, given how little explanation is provided by Microsoft and having pointed out all the problems related to their reliance on CSP as a reason, I think it's more likely that they want to remove the filter code from the browser. The filter is a feature that will need to be maintained, updated, tested and everything else that comes with having a complex feature. It's also related to the security of the browser so it probably requires more attention and scrutiny than other features too. Removing the filter will probably remove a significant piece of work and I can't help but wonder if that's the real reason behind the decision. There was a similar proposal made to Chrome more recently too, XSSAuditor Retirement Plan Proposal. It's worth taking a read of the proposal and the resulting responses for more context but I think it's fair to say that the XSS Auditor will be staying in Chrome, the issue was closed as "WontFix" on the same day it was opened.