An important concept to keep in mind when designing web applications is that business rules must be enforced on the backend, by the API. In this article, I will demonstrate why this is crucial and how avoiding to do so will open up your application to security issues and bugs.
What Are Business Rules
Before jumping in to the technical stuff, let me clarify what I mean by business rules so that we are all on the same page.
Business rules, sometimes referred to as business logic or application logic, are what governs how your app should function and what validations to apply. For instance, a business rule at Twitter is that tweets cannot contain more than 140 characters (if we dumb it down for the sake of this example and remove logic such as URL shorteners, replying to someone, etc). This means that before sending a tweet, Twitter needs to ensure that it respects the character limit.
I'm over the character limit 👆.
Where this validation should be made is exactly the topic of this article. Let's dive in!
Client-Side Validations
Client-side validations are useful in order to provide immediate feedback to the user, which makes for better user experience. For instance, when writing a tweet, we can instantly see if we went over the 140-character limit or not.
However, client-side validations are not enough on their own since they are easily bypassed. Browsers (and mobile apps for that matter) can be "hacked" or toyed with in order to bypass certain restrictions put in by the application's developers. In fact, browsers allow you to inspect and modify the html and JavaScript quite easily, so it's a bad idea to count only on frontend validations.
For instance, it's easy to re-enable the Tweet button in the browser even if we went over the 140-character limit. By doing so, we are bypassing the client-side validation and sending the longer tweet to the backend, as so:
-
Re-enabling the
Tweetbutton:
-
Sending the long tweet to the backend, as seen in this POST request:
-
This is gracefully handled on the server and a friendly error message is displayed to the user:
To protect the integrity of your data and app, it is essential to enforce your business rules on the backend as well.
Backend Validations
Backend validations allow you to take another look at the data - now that it's made its way from the client to the server - and ensure that it respects the business rules. In our previous example, this is where you would ensure that the tweet being sent is indeed 140 characters or less. If not, the server should return an appropriate error to the client so that it is handled gracefully and the user knows what to do next.
The backend is also where you can ensure data integrity by validating the information being saved to the database, making sure it does not contain any ill-intented information, that the types are good, etc. This should also be done at a lower level than the API, such as an ORM or even the database, but I include those in the big backend bubble. Separating concerns and where exactly to apply these validations is a discussion for another article.
One of the reasons why validations on the backend are better suited for business logic is that you have control over your server and the code executed on it, as opposed to client-side code. This is not being run in a browser or on a mobile device and is not being manipulated by a user. It is code that you wrote and know how it will behave.
Conclusion
One important thing I'd like to clarify here is that both frontend and backend validations are important but their main goal is different.
Frontend validations are great for giving feedback to the user. Imagine having a user filling up a long form and submitting it, only for it to be rejected by the server because of an empty input, and prompting the user to re-fill the form. This would obviously be frustrating to users and is avoidable by using frontend validations.
Backend validations, on the other hand, are meant to ensure that the business rules are indeed applied and respected, and for data integrity.
I hope this was helpful and clarified the differences between the two parties. Let me know if you have any questions or comments. Thank you for reading.
This post was originally published on Designing for Scale
Top comments (6)
Asp.Net MVC really provides a clean way to implement these validations on server as well as the client side, and it does with using the DRY principle.
It allows us to use data annotations on the model which can be validators, and they are triggered on both client and server.
That's great, thanks Sumant. I haven't touched ASP.NET in a little while, I'd have to get back into it and play with this.
It's not even about "hacking" the browser. The browser's just doing HTTP (or HTTPS) requests. By using Fiddler (Windows) or Charles Proxy (macOS) or Wireshark, you can see the underlying requests. Then you can replicate the requests (with modifications) by simply using curl or Postman (for Chrome) or whatever.
Absolutely agreed! Those are great tools to understand what's going on in the communication layer. I also often use Postman to fool around with APIs and see how they behave when you try to break them. Thanks for the feedback, Roger.
This is absolutely critical info. I sometimes take for granted how ingrained this is in my mindset when I encounter developers who are not thinking along these lines.
I totally agree, Ben. It's easy to think that everybody knows this stuff but the truth is, we didn't know everything we know now when we started out. Thanks for your feedback.