3.3. Validation

You should validate all input data before transferring it to internal processing. Violation of this rule has caused numerous web sites to be subject to attacks such as Structured Query Language (SQL) injection. ^[*]

^[*] SQL injection involves using the entry fields on a web form to submit SQL commands to a database that is the backend for a web server. For more details, go to http://www.nextgenss.com/papers/advanced_sql_injection.pdf or search Google.

You should convert input to its corresponding abstract data type as it comes into the system. For example, you should convert an input field that represents a dollar amount into a variable of type Dollar . Failures of conversion (such as an amount that has three decimal digits) can be reported back to the user immediately. There is no sense in processing an invalid Dollar .

All identifiers should contain self-validating values that can prevent most common entry errors. For example, if a PhysicalID was used to identify each CDDisc , it should contain a check-digit or other error-detection mechanism. Common typing errors can be caught at input, instead of being passed along as erroneous data. ^[*]

^[*] It is ironic (or perhaps a rhyming term ) that one of the most widely used identifiers, the Social Security number, has no check digit.

The most stringent rule is that the value of every parameter to every method should be subject to validation . The rule can be relaxed if the caller of the method (or its caller) has performed the validation. If an attribute is set from a method called from the outside world, the setting method should check for validity. If the value for the attribute is read from a configuration file, it should be checked. If the attribute is set by data read from a database and that data was placed there by the system, the checking needed is minimized. The data should have been stored only if it underwent validity checking. The paranoid developer might still want to check it.

Paranoia is not necessarily a bad thing, unless it hinders code interpretation or performance. Some error-handling routines might never be invoked. That is not necessarily a bad thing. It is better for a doctor to double-check the blood types of a heart donor and its recipient before doing a heart transplant than it is for her not to double-check. If the double-check never fails because a mismatch never occurs, the error procedure ("Get another heart") is never executed.

For systems that involve two or more programs, such as a browser/web server, validation can occur in both programs. Validation in the server before further processing is mandatory. Validation in the browser provides error checking without round trips to the server.

On layered systems, validate at the boundary of each layer, according to the contract defined between the layers . For example, the model layer should validate the data feed from the display layer before processing it.

If the data is invalid, the method should report the error according to the "Decide on a Strategy to Deal with Deviations and Errors" guideline discussed later in this chapter. It should not pass along the invalid data, but terminate the processing of it.

VALIDATE, VALIDATE, VALIDATE

At each interface, validate that the input matches the contract.