(enlarge)I have explained in The Three Steps of Building an ASP.NET Validator Control, how to build a validator control from the ground up in three easy steps and in a reusable format. I highly recommend reading it before going any further.
Here I am discussing the common validator control security holes that might compromise your forms’ security when left untreated.
Security Hole 1: Failing to Implement the Server-Side Validation
When building a validator control from scratch or using a CustomValidator, you should always implement server-side validation (i.e., the .NET code); the client-side validation (i.e., the JavaScript) is optional but nice to have.
The reason is that a malicious user might disable JavaScript in their browser to bypass your validation, or might not even be using a browser but some code that posts to your form.
Always start by building the server-side validation, test it, then start building the client one.
Security Hole 2: Failing to check Page.IsValid
This is a major pitfall and failing to avoid it will render your validation next to useless! Before you process any data coming from your form, you need to make sure that it has passed your validators. However, if the client’s browser has JavaScript disabled, the code will reach the server without validation, and you will need to check Page.IsValid manually. For example:
protected void Submit_Click(object sender, EventArgs e) {
// Very Important
if (!Page.IsValid) {
return;
}
// Do some processing here...
}
Security Hole 3: Client-Side and Server-Side Regular Expressions
Regular expressions, aka regex, may not have the same effect on the server side as on the client side. In other words, the same regular expression syntax that works on the server side might not work on the client side, so make sure you thoroughly test both.
Security Hole 4: Relying on the MaxLength property of a TextBox
This is not directly related to validator controls; however, it belongs to validation, and I thought I would mention it for completeness.
You should not rely only on MaxLength to restrict the maximum allowed text in your TextBox, as this property can easily be bypassed on the client — by setting the TextBox with JavaScript, for example — and is never checked on the server side. However, set it anyway for usability purposes.
To force a maximum length on a TextBox, you might use a RegularExpressionValidator with the validation expression ^.{0,MaxLength}$.
Always test your validators in both modes, JavaScript enabled and disabled. To turn off JavaScript in Internet Explorer, you can go to “Security Settings,” though I recommend using the Internet Explorer Developer Toolbar.
If you think there are more security holes worth mentioning, please leave me a comment.