The other day, my colleagues and I were discussing an application behavior and one of them mentioned the phrase “Garbage in, garbage out”. Is that an acceptable application behavior? I don’t think so. Application design should prevent it from accepting the garbage in the first place. Even if the garbage does manage to get into the application, we should not allow it to exit it. Failure to stop garbage from influencing the application outputs is sign of a non-secure and sloppy programming. A data contract needs to be defined when designing application interface. The contract usually consists of pre and post conditions.

Stopping garbage in
The application inputs should be sanitized based on the pre-conditions. The execution could only proceed if the input data has satisfied the pre-conditions. With programming tools such as “if” statements and/or assertions we can enforce pre-conditions and therefore prevent from the garbage from polluting the application.

Stopping garbage out
Regardless of the application inputs validity, the application should never output invalid information. The data contract needs to define post-conditions. Before outputting the information, the application should verify the data, making sure it satisfies the post-conditions. Depending on the application output data structure, the post conditions may check for null object, range of valid values, number of elements, empty string, etc.

Conclusion
An application should contain an interface data contract. The purpose of the contract is not only making sure that garbage input does not negatively influences application, but also making sure that no garbage is outputted. As an added benefit, the pre and post conditions, which are part of the data contract, server as executable documentation.