Your users are lying to you.
Not necessarily intentionally.
Your users can be honest, malicious, or simply sending something your application didn't expect.
You might be building a web app, a mobile app, an ML model, an AI agent, or whatever, but if it is being used by users, there are high chances it has some kind of interface and a server.
From beginners and college students to big companies, all of them have had small or major failures in handling bad user input.
The major reason according to me is assumptions.
We make assumptions about the kinds of users of our product, but in this process we forget the following: If our product is in public, people other than our target audience might use it as well, who may not be trustable Even our target audience may include various kinds of people who might have bad intentions or may simply not understand what input is expected from them Recently, in one of the softwares that me and my team had developed for my college, I faced this issue where students were required to upload a PDF file to some storage on the internet (like Google Drive or DropBox) and enter its URL in a certain form field.
We didn't do proper checks on the backend assuming everyone would enter a proper URL.
However, certain students (for whatever reasons!) entered the path where the required PDF file was stored on their local computers.
This was an innocent and a funny event and did not cause major issues, but strengthened my belief in the fact that we must not make any assumptions about user input.
What happens if I don't do this?
The trouble this could cause is highly variable.
It could simply lead to a request failure, or cost you a lot of money.
So in my opinion, learning to handle bad user input is really important, and never trusting user input from frontend and handling it on the backend is a rule that I now follow and I recommend every software engineer to do so as well.
I will now try to list down few good practices, scenarios, mistakes and their solutions which could help you write better software.
These will range from simple to complex issues.
However the list is not exhaustive and it is suggested to think over the different cases for your own software.
Thumb Rule: Frontend form validation is necessary but not sufficient Frontend validation includes allowing only specific inputs and input formats to be sent to the server.
This can be done in multiple layers.
Taking example of a web app, the first layer would be to use HTML attributes properly.
For example, for an email field in a registration form, you can have a tag like this: Another really important layer would be validating your input programmatically before sending it to the servers.
So for example, in a web app, you could do the validation through JavaScript.
This includes things like checking formats through regex, checking data types, empty inputs (for required fields), etc.
This is extremely useful because it decreases potential load on server by allowing lesser number of useless API calls, and because of this if there is any bad input, it can be caught earlier before the request reaches the server, and hence makes the user experience better.
However, all these could be worked around to bypass, especially in a web application using developer tools of the browser.
And hence are not sufficient.
Similar checks must be done on the servers before doing important actions like accessing the database.
It is not only about saving load on the server by not allowing bad requests.
Doing proper string format checks on both client side and server side adds a security layer for serious attacks like SQL Injection (Read more about SQL Injection).
This does not prevent it always but might act as an early catcher for some cases.
Start using schema validation libraries Using schema validation libraries is really good way to solve this problem.
Some examples of these are zod, joi, and yup for the JS ecosystem, and Pydantic for python.
For other programming languages