Server-side vs. Client-side Validation – CompTIA Security+ SY0-401: 4.1

| September 14, 2014 | 0 Comments


Should you validate input data on the server, or on the client? In this video you’ll learn the advantages and disadvantages of using both of these validation strategies.

<< Previous Video: SQL and NoSQL DatabasesNext: Mobile Device Security >>


One of the ways the bad guys like to get into your systems is they try to give it information that the system or the application is not expecting. And if they can do that in a way that they can predict the outcome, they may be able to gain access to data or systems that normally they would not have access to.

To try to combat this, what we want to do is to validate all of the input that the end user may be making to that application or into that service. One of the ways to do this is on the server side. The end user is typing in information and they’re sending it to the server to be evaluated. Maybe they’re sending a sequel call. Maybe they’re registering on a website or they’re looking for search information. And what we’ll do is grab that registration information or have a look at that search query to determine if this is really a valid query or valid input, and we do that once the information has been sent to this server when you’re doing a server-side validation.

This is really going to help against those malicious users who are trying to take advantage of some shortcomings in your programming or they’re trying to find a way around the interface of your server, and by checking it on the server side, you can make sure that you’ve got the final step before anybody is able to get to the data or get to the system. We could, of course, do this validation at the user side before it’s ever sent in to the server. So if the user has an application that they’re using or they simply have a browser front end to this application, we would have some intelligence built into that application that checks the query first and if all of the query information looks OK, everything seems to match up, it’s not trying to take advantage of any vulnerabilities, we’ll then send that query off to the server.

One of the challenges with this is that it could filter legitimate input from the user. You have to be very careful about how you design those validation checks especially if it’s all being done at the client side. If you make a mistake with those validation checks, you’re then going to have to update all of your users’ applications so that you don’t make that mistake in the future. This can also provide some additional speed since you’re doing these checks down on the user side where generally you have more computing resources available. On the server side, the servers are very busy doing a lot of things, and if you’re doing validation checks on the server, it may take additional time.

You really want to use both server-side and client-side validation, so you want to validate as much as possible on the client side. But some clients are smart. The bad guys will use a third-party application that looks and feels like the original app and sends information to the server, so they can circumvent any client-side validation you may have in place. So for that reason, you want to also have your server-side validation so that once the data arrives at the server, you can perform the normal checks and make sure that nothing odd is going on with the information being sent in to your server.

Tags: , , , , , , ,

Category: CompTIA Security+ SY0-401

X