I'm having problems with requests that include 'dangerous characters' as part of a Web API URL. The Url includes an & which is properly Url encoded, but still causes a Request Validation ASP.NET error.
Unlike MVC there appears to be no [ValidateInput(false)] attribute to force and disable this functionality.
Turns out the answer is to do this in web.config using:
You can set this globally or at the sub-directory level. You can leverage the
<location path="">
element to specify this setting only underneath certain paths. For example, if your Web API route that was affected lived underneath api/images you could do the following:More information: https://msdn.microsoft.com/en-us/library/e1f13641(v=vs.100).aspx
With RequestValidation set to 4.0 in the configuration the answer is no. You can however revert back to 2.0 Request Validation in which case the MVC attribute works as you would expect: Validate by default and explicitly override when needed.
Talked in detail about this and some of the options here: http://www.west-wind.com/weblog/posts/2010/Aug/19/RequestValidation-Changes-in-ASPNET-40
You can get more fine-grained control over this by setting the
requestValidationType
attribute of thehttpRuntime
element to a custom type that inherits fromSystem.Web.Util.RequestValidator
and overridesIsValidRequestString
.Unfortunately this isn't part of the WebAPI pipeline, so can't directly check for things like action filters (i.e. attributes on controller methods).
However, if you specifically care about the Validation of Form fields, the Validator doesn't get called on these until you access them, which happens after Action Filters are fired, so you can opt-out of validation using an attribute by creating classes like the following...
... Then just annotating your controller method with
[AllowFormHtml]
However, if you're accessing form fields directly from the HttpRequest, it's simpler to use
HttpRequest.Unvalidated
, which bypasses validation.per @Levi our Web Security guy:
Config is the only way to do this. Even MVC’s [ValidateInput(false)] wouldn’t help with this particular scenario.
Disabling it in Web.config isn’t necessary a terrible idea. If you’re following good security practice by validating and encoding untrusted data, it’s perfectly fine to apply it application-wide.