Don’t call me Shirley!

The other day someone came into my office and asked: “Why should I have to validate the web form input at the web server? Surely it better to do it in the browser!”

*Humph!*

“I can think of many reasons why you are wrong”, I said, “and don’t call me Shirley!”

Firstly, and I can hear the clockwork ticking over in many web developers heads, you may get a slight performance improvement if you don’t validate the input at the server. However, any gains need to be offset against the losses. Are you willing to risk the chance [did I say chance? I mean damage!] that an attack will do for a mere millisecond or two gain in performance? Lets think about it logically: are users really going to gain anything by you doing this? Simple answer : NO!!! The user of your web application is never going to notice and doesn’t even care whether you do the validation of the input in the browser, server or Timbuktu! Save your users and save your web application by always validating at the web server!

Secondly, there are many intercepting web proxies that can be used to extract and manipulate the parameters of a web form after validation. Even if the validation is in the browser this does not protect your web server. Also, there is nothing to stop me as a developer cloning your web form, removing the validation and then submitting to your application. Again, this renders the input validation useless.

Finally, many of the main web server or web application server vendor solutions (think IIS / ASP.NET or Oracle Application Server  or JBoss) include in the framework the ability to validate the input data against a specified subset of character or data type. In ASP.NET you have to explicitly change the configuration in order to turn it off. If it’s already there, use it! Don’t go re-inventing the wheel just because it sounds like fun.

With these words of advice ringing in his ears this individual went off with their tail between their legs – and he’s never called me Shirley since!