There's a great discussion going on over at Rob Conery's blog - where he's asking for feedback on how to handle encoding options to prevent XSS when using the new ASP.NET MVC. In my mind this is a BIG deal because of just how well traditional ASP.NET (that's weird to say) has handled the task of squelching XSS in the past. It's also a big deal because I really want the MVC to remain as absolutely 'clean' as possible - as in free from 'magic' and other "we're helping you" type of stuff that addresses 90% of use-cases but shoots experienced web developers in the foot on 'edge cases' surrounding standards support and the likes.

So, since Rob is asking for feedback, I thought I'd provide in the form of a blog post (where I can more easily whip-up my thoughts without having to fight inside of a textbox).

What shapes my thoughts/rationale:
Most people interested in using the MVC are going to be more advanced ASP.NET users (and real-life web developers) that are looking for two key things:
a) Greater control over emitted markup (while still being able to leverage the .NET Framework) and
b) Greater separation of data, presentation, and logic. In other words: less intermingling, and less coupling between those realms. Or, stated differently, less 'magic'.

It's also a no-brainer that MVCs are HIGHLY reliant upon convention (at least initially) - which means that co-opting security practices into the convention should be the best way to attack this issue.

My Preferences for handling XSS Encoding:
1) Leave the responsibility for encoding entirely up to developers. But make it part of the convention. And provide some decent syntax support that makes it logical and easy. In my mind this would allow the greatest degrees of control and separation - yet still make it possible to achieve good security. (Me, I want ALL THREE options (control, separation, and security) - one or two of the three just isn't good enough.)
2) A slightly less perfect approach would be to Encode everything on the way out - as long as there's a way for developers to turn that off (without too much hassle) in the few cases where they'll actually want to do so. That would be tolerable in my mind as it would let MS feel like they had done their best to protect dumber web developers from shooting themselves in the foot, but wouldn't make the rest of us pay too steep of a price. (I still maintain that any time you try to make something more fool-proof you sadly just end up creating better idiots.)
3) The worst option, in my mind, would be to encode on the way in. That quickly shoots clean separation out of the water, and assumes that you'll only ever be using your input data in another web application - which represents HORRIBLE coupling. I think everyone can see that - even if the argument could be made that you're potentially opening yourself up to a 2nd-Order attack by persisting XSS or SQL Injected code.

That said, I'm certainly LOVING the MVC. It's honestly one of the best things to happen to ASP.NET ever. (I get clean separation, complete markup control, and all the benefits of sitting on top of the ASP.NET and .NET framework - all in one tidy little package.) I also think that the learning curve it presents is significantly less than the jump from say Classic ASP to ASP.NET, but I also think that it will result in developers writing CONSIDERABLY less code to get well-functioning apps up and running. More importantly, I finally feel like Microsoft has addressed real-life web-developer needs with a flexible framework - instead of focusing so intently on creating tools for applications developers to make web applications. In other words, I 'feel' like the focus here is more on web sites than on intranet applications - which is VERY exciting to me as I spend most of my dev energy working on sites instead of clunky/massive/enterprise-y intranet applications. (Though, that said, intranet developers should rejoice as well - as the MVC should make their lives easier too if they're looking for standards-compliant markup and cleaner separation as well as a less-monolithic approach to application testing and maintenance.)