Techniques to avoid input validation errors

As you develop code, keep this tenet in mind:

ALL input is hostile until proven otherwise.

Never trust the client. Never trust the server. Even if the entity has authenticated, it should still be considered hostile. Successful authentication does not show intent. This means that you should assume that parameters sent to object methods or functions are sent by a hostile entity. Besides being more secure, you will also catch reliability bugs in the code. Expect the unexpected.

Worth noting is that I have found that impossible conditions occur at least once a month, so you should have code to check for them. In languages that support them, use exceptions for these impossible situations.

There is a line you have to draw. Too much error checking and handling can obscure the real purpose of the code. At some point, you have to draw a line. Personally, I often draw the “trusted/untrusted” line at the object boundary. When data comes into an object, I do thorough input validation on it, calling validation methods as appropriate to encapsulate common code. Once data have made it in, I presume that it has remained valid. Note that in some circumstances, this assumption is not valid, so be sure to do the right thing for your specific project.

Assume everybody is out to get you. If they are not, you can receive a pleasant surprise. It’s better than the alternative.