Bryan here. Since Steve called me out in his post on the XSS Filter last week, I feel obligated to clarify my position. ☺ I believe that the SDL blog is mainly for development teams; after all, development is the D in SDL. Now, development teams are made up of more than just developers. Development teams include everyone involved in the development process from management on down. But development teams don’t include end users. While XSS Filter is a great, innovative XSS defense technology, there’s really nothing that development teams can do to take advantage of it. Users alone make the decision as to whether they’re going to take advantage of XSS Filter: they either use IE8 and get it, or they use another browser and don’t get it.

That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.

But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ☺) Then would we relax the server-side XSS defense requirements? Yes, we probably would.

I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.

We now return you to your regularly scheduled development-focused blog.