Some of our customers have indicated to us that their own and/or third-party security audits reveal a shortcoming in our default web.config, where we set validateRequest="false".
While it is true that Microsoft's intent in introducing the feature—mitigation of injection attacks—is noble, we find their approach heavy-handed for operating any web application that has appreciable user input. We are trying to strike the right balance between user experience, functional requirements, and best practices for security policy.
In one of their own white papers, they explain:
"Request validation, a feature of ASP.NET since version 1.1, prevents the server from accepting content containing un-encoded HTML."
An example therein demonstrates that enabling request validation can easily create a user-facing exception from very basic input.
In the worlds into which we introduce Engine, we know that xAPI, SCORM and AICC content can easily send non-ASCII characters that are unencoded. We have a handful of pages that user data gets posted to, and if Engine is operating in a standalone application, setup is considerably easier with a general policy of not leaving it up to IIS to reject all un-encoded content.
In the future, we might offer more precise default settings for web.config and our ASP.NET pages that accept HTTP POST, but for now we'd rather entrust security policy to our customers than to Microsoft.
N.B. As of the .NET Framework 4.0, validateRequest is no longer used by default. In order to enable it, requestValidationMode="2.0" must be used to indicate that .NET Framework 2.0 default behavior is preferred to the 4.0 default behavior of validating any HTTP request data.