was successfully added to your cart.

Where Should I Validate Data in my Application?

Where Should I Validate Data in my Application?

By May 11, 2018 Ask Tim One Comment

Which Layer is the Right Layer?

 

When you are writing an application that has many layers, the question often comes up as to where do you validate. I have heard a number of answers on this but I think there is, in general, one right (or at least best practice) answer: everywhere. Let’s think about a web application I built for my company. It has a JavaScript user interface, a C# WebAPI middle layer, and a SQL Server database (very simplified version of our application). Now we can talk through the layers in my application and you can apply the principles to your application.

The JavaScript UI Layer

When a user fills in a password field and the requirements state that a password must be 8 characters long, when do you want to tell them that? My thought is right away. So that means you need to have some validation written in JavaScript that checks the password after they typed it out before they submit the form. Now you could wait until the form submits and then come back with an “invalid password” error message but now you added a round-trip to the API just to validate data. That isn’t efficient and it isn’t user-friendly.

Other scenarios might include ensuring something was in the shopping cart before checking out, verifying that a product could be added to the cart right away, and other issues that should be handled right away rather than waiting until the user tries to finalize an action or submit a set of data.

The API Layer

Once the shopping cart, for example, gets submitted to the API, do we check it? In theory the JavaScript has already validated it so we should be good. The answer is yes, you need to check the data. JavaScript can be manipulated or bypassed. SQL injection happens because people trusted data coming from the user interface. You must check the data at the API level. That means you will have validation written in C# to check for a lot of the same things you checked for in JavaScript, although you will probably have more checks in the API.

The Database Layer

Surely by this point you trust the data coming into the database, right? Not so fast. The answer is more a “probably” rather than a firm yes. Think for a minute about your application. Is it the only one that will put data into the database? Ever? If you answer yes to that question, your application is either really small or hasn’t been around long enough for you to see the long-term use. Your application is not directly tied to your database. They are loosely coupled (hopefully). That means other things can and probably will use just your database (reporting servers, new third-party applications you acquire, etc.) That means you won’t always be in control of what updates your database. You also won’t be in control if a user captures your database credentials and uses them directly. That is why your database too needs at least some basic validation. That may include foreign keys and referential integrity, it may mean limited access accounts, or it may mean logic in stored procedures.

The Bottom Line

Validation should happen multiple times and you are going to duplicate logic. That is the price of doing business. What this all comes down to is trust and control. You should not trust anything accessing your application stack at any layer. JavaScript can be bypassed, credentials can be used directly in SQL, and mistakes can be made by developers. On the other side, you don’t have control of the full stack as one continuous unit. In a perfect world, people will only go through the JavaScript UI to put data in and it will be safely transported all the way to the database. However, that isn’t how the real world works. Instead, your UI is disconnected from the API, which is disconnected from the database. You don’t have control over those boundaries. If you did, you would have one ugly, monolithic application and that is a different issue.

Join the discussion One Comment

Leave a Reply