Principles to follow when validate data in your codes/application
By: Kemoy Campbell
Tags: Guidelines, Technology, Guides And Tutorials, Data Validation, Programming

Before I get to some of the important principles to employ when validating data in your application, I would like to briefly go over what is data validation and why it matters.

What is data validation?

Data validation is the process of validating your data to ensure the accuracy, reliability, and quality of the data. In another word, if you process data and that data get stored in your database, used throughout your application or passed off to the marketing department, the department should be able to trust the data because they are reliable.

Why does data validation matter?

Unexpected data can cause the application to behave differently, i.e. entering an unexpected state, and introduce security risks. Some input data are intentionally designed to exploit an application. Data are used to make business decisions. Incorrect data can result in the loss of revenues. Data can be the difference between life and death. Think in the case of healthcare. An incorrect data can lead to the wrong diagnosis!

The above mentioned examples are not an exhaustive list of why data validation matters but they are sufficient to give you a clear picture of why it matters.

Principles for data validation

First and foremost, NEVER TRUST ANY INPUT DATA. Always work under the assumption that the data is unsafe, malicious and contains some arbitrary codes to break/exploit your application.

Enforce the acceptable data types such as string, integer, alphanumeric, etc. In short, make sure the input data is what you expected.

The length of your data matters. If you are storing data in the database, ensure that the data can fit within the defined length restriction on the database or any preferred storage mechanism.

I cannot emphasize this one enough: every method should validate its data regardless if the data might have been validated elsewhere outside of the method or in another method. Let me illustrate what I mean:

As we can see in the snippet above, there is validation happening in methodA before calling someMissionCriticalMethod. There is no validation in someMissionCriticalMethod and it depends on methodA to do the validation prior to calling it. What would happen when another developer on the team called someMissionCriticalMethod directly? Of course, this is likely to result in bad things. Therefore, it is important that all method should perform its own validation.

I would like to call this one “validate once”. I have seen many cases where lines of codes to validate a piece of data are introduced repeatedly in many functions. This breaks the DRY principle. Moreover, we can move the block of codes that is responsible for validation to a class. Furthermore, we could also use an interface which we can then use as the parameter’s type hint. Take a look at the snippet below that validates an email address:

As we can see from the snippet above, it violates the DRY principle and introduces an repeat of the validation code block. We can refactor this to a cleaner approach as demonstrate in the snippet below:

Email Validation Refactor

While it is true that we introduce additional codes by adding an interface and a class that performs the validation, the trade-offs are an acceptable. The method now adheres to a single responsibility, email validations are enforced, code is more readable and easy to maintain.

Never skip the backend validations. I have seen so many cases where the developers performed validations on the frontend but did not do the same on the backend. Frontend validation can be easily bypassed. The user can easily turn off the JavaScript or an malicious actor can make a request directly to the POST OR GET URL which can result in catastrophe. It is nice if you perform validation on both ends, but if you have to choose, always validate on the backend.

Conclusion

It is important to recognize that this is not an exhaustive list of guidelines while validating data, as there are more steps involved depending on the domain, business rules, regulations and nature of the application. However, this is the basic data validation guideline that one should follow when designing an application.

We have only scratched the surface of data validation. This is meant to be a quick read. If you are interested in more in-depth details, I recommend the following links: