Client-Side versus Server-Side Validation

If you are new to Web application development, you might not be aware of the difference between client-side and server-side validation. Suppose that the end user clicks the Submit button on a form after filling out some information. What happens in ASP.NET is that this form is packaged in a request and sent to the server where the application resides. At this point in the request/response cycle, you can run validation checks on the information submitted. Doing this is called server-side validation because it occurs on the server.
On the other hand, supplying a script (usually in the form of JavaScript) in the page that is posted to the end user’s browser to perform validations on the data entered in the form before the form is posted back to the originating server is also possible. In this case, client-side validation has occurred.
Both types of validation have their pros and cons. Active Server Pages 2.0/3.0 developers (from the classic ASP days) are quite aware of these pros and cons because they have probably performed all the validation chores themselves. Many developers spent a considerable amount of their classic ASP programming days coding various validation techniques for performance and security.
Client-side validation is quick and responsive for the end user. It is something end users expect of the forms that they work with. If something is wrong with the form, using client-side validation ensures that the end user knows about it as soon as possible. Client-side validation also pushes the processing power required of validation to the client, meaning that you don’t need to spin CPU cycles on the server to process the same information because the client can do the work for you.
With this said, client-side validation is the more insecure form of validation. When a page is generated in an end user’s browser, this end user can look at the code of the page quite easily (simply by right-clicking his mouse in the browser and selecting View Code). When he does so, in addition to seeing the HTML code for the page, he can also see all the JavaScript that is associated with the page. If you are validating your form client-side, it doesn’t take much for the crafty hacker to re post a form (containing the values he wants in it) to your server as valid. Cases also exist in which clients have simply disabled the client-scripting capabilities in their browsers — thereby making your validations useless. Therefore, client-side validation should be considered a convenience and a courtesy to the end user and never a security mechanism.
The more secure form of validation is server-side validation. Server-side validation means that the validation checks are performed on the server instead of on the client. It is more secure because these checks cannot be easily bypassed. Instead, the form data values are checked using server code (C# 4 or VB) on the server.
If the form isn’t valid, the page is posted back to the client as invalid. Although it is more secure, server side validation can be slow. It is sluggish simply because the page has to be posted to a remote location and checked. Your end user might not be the happiest surfer in the world if, after waiting 20 seconds for a form to post, he is told his e-mail address isn’t in the correct format.
So what is the correct path? Well, actually, both! The best approach is always to perform client – side validation first and then, after the form passes and is posted to the server, to perform the validation checks again using server – side validation. This approach provides the best of both worlds. It is secure because hackers can ’ t simply bypass the validation. They may bypass the client – side validation, but they quickly find that their form data is checked once again on the server after it is posted. This validation technique is also highly effective — giving you both the quickness and snappiness of client – side validation.