Anil has some interesting observations about Julia's posting on the ASP.NET Request Validation feature in ASP.NET 1.1, which provides some protection against cross-site scripting attacks.
A bit of background on this feature:
After we shipped v1.0, one of the pieces of customer feedback we got was that it was too easy for developers to make the mistake of leaving their site unprotected from cross-site scripting attacks. In fact, Dmitry, our dev manager, actually went on several prominent commercial sites (some, but not all, running ASP or ASP.NET), and found that a few were prone to cross-site scripting attacks.
As part of the philosophy of securing by default, we decided to create the request validation feature, and turn it on by default, so that all pages immediately got protected. Of course, this meant we'd have the usual problem for security lockdown types of issues, which is backward compatibility. If your page actually expects input that would be blocked by request validation - for example, HTML text with tags - your page would break by default.
So, we provided two ways to turn it off. First, on an individual page basis:
<%@ Page ValidateRequest=”false” %>
And secondly, on a whole site basis by changing the <pages> section of web.config.
The recommendation, of course, was that you turn off the minimum number of pages you need to turn off, but only after verifying whether the page encodes request variables properly. As Anil said, if a 3rd party app you receive abuses this, or a control vendor tells you to turn this off for the entire app, you should rightly question whether the app or component is secure.
There's also some programmatic access to request validation - Victor's post explains this stuff really well.
Note: As G. Andrew Duthie points out on Anil's post, we didn't quite get it right the first time - there's been a patch to fix a problem in this feature.