Client side validation Vs. Server side validation
Client side and server side validations are both types of ways of checking the accuracy of inputs but they are vastly different aspects of web development. Client side validation is a UI/UX design feature whereas server side validations are integral components of security and data handling.
Client side validations serve to guide the user to make good decisions about inputs they’re entering into form fields or other places on a GUI where information is requested. If a user types in an email address into an email field and forgets an “@” symbol, when they click out of the input field a message may appear informing them of their mistake. Moreover, the user may not be able to proceed to hit “Submit” unless they first fix the error; no HTTP request is made as a result. This can be done via native HTML validation functionality, i.e. by setting minLength or required=true attributes, or via JavaScript, i.e. on clicking “Submit”, code is run on the input which determines whether or not to display error warnings to the user. Hence, client side validation here has served to point the user in the right direction.
At HealthCare.Gov when we were remaking the application to be more streamlined, I implemented all client side validations to help keep users from entering improper data into the lengthy form. This included rules for dates (if dates had to be within bounds), for response input length (if responses couldn’t be more than x amount of characters), data type (no letters in your social security number, no special combination of numbers in social security, as the SS administration would consider those typos), email validation (which I messed up on maybe 4 times to the ire of our government partners). All of these validations showed the user their error up front, which ultimately helped them progress through the application. This is because if users get warnings ahead of time, as a developer you can potentially save yourself a failed HTTP request; if a users improper data goes through to the server and it is the server that spots errors, it has to boomerang the failure back to the client, which then has to to let the user know that they’ve made a mistake. This slows down the entire application process. The more you slow down a process, the trickier it can be to get users to the finish line, whether that is them finally clicking the “Submit” button at the end of the form, or whether it’s checking out a cart during online shopping. You want to do everything in your power to limit the drop-off rate. The more hurdles you put in a user’s way, the more detrimental it can be for their health, i.e. if they abandon the healthcare eligibility application, or for your wallet, if they abandon the cart because something distracted them.
Server side validation on the other hand has less to do with user experience and more to do with how incoming data is actually going to be processed and stored. This type of validation is equally and if not more important. For example at HealthCare.Gov we used a 3rd party API midway in the process of the user filling out the entire form. We sent whatever preliminary data that we had collected to the API to see if the user was qualified for some government premiums like CHIP (Children’s Health Insurance Program) or Medicaid/Medicare. Just because there is data that reaches the server of course does not mean that it is valid or correctly formatted. Before we sent data over to the 3rd party government API, it was important that the data was in exactly the right format that the API was expecting. For example, if we asked users if they were currently pregnant and asked for a tentative due date, if they put in a date from 3 years ago, it could cause an error. The same was the case if we asked users if they were incarcerated in the last two months and they answered yes and input a date of their release 3 months prior. Having data accuracy is important especially when dealing with government agencies which must (strive) to be law abiding. Thus, on the server side, you need to do checks because the data needs to be passed along to another API which itself may have checks for the user data that you submit over to them. If the API comes back with an error, and you didn’t do validation checking on the server side, then you may or may not be able to track down the cause of the error. Even if the 3rd Party Api tells you where the error occurred, if you don’t have a proper way of handling that particular error, like sending the user to that specific part of the application where the error occurred, you’ll then need to pivot and have to user customer support in order to address that issue. That means more money that is being put into fielding errors when they could have been prevented with better engineering and design. Moreover if you allow users to submit information that is outside the bounds of the question, you might potentially be putting them at risk or violating the law. So it becomes very important to have proper data so you can send it off to agencies. You want to prevent user error as much as possible.
Server side validation is also important because it helps prevent dangerous code from interacting with your system. The classic xkcd comic illustrates this point.
There are many ways to send information to an API endpoint without going through a graphical user interface. You can use a curl command or Postman or some other tool. This way you can bypass client side validation entirely. Therefore, client side validation is completely useless in protecting your system from dangerous input. As soon as data hits the server, the validation process needs to begin so that malicious inputs are discarded and unable to proceed through the data pipeline. It is critical for data integrity as well as confidentiality. If there’s SQL code requesting the names, birthdays,and social security numbers of your users that you haven’t protected against, now you have a problem. If they delete all entries in your database, or store inappropriate content in the database that users later encounter, it could be the end of your entire organization.
SQL injection usually happens when the client side is responsible for generating the queries which are fed to the server and passed along to the database. Generating the SQL statement on the server side is one way to mitigate this from happening, by having more control over the statement, or by using an ORM like Sequelize or Mongoose which generates specific queries for you. Of course ORMs can still have bugs or rely on packages which have vulnerabilities, so making sure the data coming into the server is safe is a first critical step to safety. This can be done effectively by blacklisting or whitelisting certain characters or sequences of characters. If you’re using regex to do this it’s important to get it right, and that alone can be an extremely complicated task, and as an industry it is not a skill that’s frequently mastered. Security hence is often a game of doing the most you possibly can and recognizing that there is almost never a complete bulletproof solution to a security problem.
To wrap up, front-end validation is more a UI/UX design feature than it is a hard engineering feature because we’re trying to point the user to a desirable input. Server side validation mitigates security risks and ensures services are using accurate information.
