Input validation serves as a first line of defense for a web application. Many vulnerabilities like SQL injection, HTML injection (and its subset of cross-site scripting), and verbose error messages are predicated on the ability of an attacker to inject some type of unexpected or malicious input to the application.
When properly implemented, input validation routines ensure that the data is in a format, type, length, and range that is useful to the application. Without these checks, the confidentiality, integrity, and availability of an application and its information may be at risk.
Data validation can be complex, but it’s a major basis of application security. Application programmers must exercise a little prescience to figure out all of the possible values that a user might enter into a form field. These tests can be programmed in JavaScript, placed in the HTML page, and served over SSL.
The JavaScript solution sounds simple enough at first glance, but it is also one of the biggest mistakes made by developers. Client-side input validation routines can be bypassed and SSL only preserves the confidentiality of a web transaction. In other words, you can’t trust the web browser to perform the security checks you expect, and encrypting the connection (via SSL) has no bearing on the content of the data submitted to the application.
One of the biggest failures of input validation is writing the routines in JavaScript and placing them in the browser. At first, it may seem desirable to use any client-side scripting language for validation routines because the processing does not have to be performed on the server. Client-side filters are simple to implement and are widely supported among web browsers (although individual browser quirks still lead to developer headaches). Most importantly, they move a lot of processing from the web server to the end user’s system.
