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
Always start by building the server-side validation, test it, then start building the client one.
Security Hole 2: Failing to check
Page.IsValid manually. For example:
Security Hole 3: Client-side and Server-Side Regular Expressions
Regular expressions AKA RegEx on the server-side and the client-side may not have the same desired effect, 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
This is not directly related to validator controls, however, it belongs to validation and I thought of mentioning it for completion.
You should not rely only on
MaxLength to restrict the max allowed text for your
TextBox as this property can be easily bypassed on the client, by setting the
To force a max length on a
TextBox, you might use a
RegularExpressionValidator with the validation expression
If you think that there are more security holes that are worth mentioning then please drop me a comment line.