Why is client-side validation a security risk as opposed to server-side validation?

Question

I don\'t quite understand why client side validation is a potential security risk or more of a security risk than server side validation? Can someone give me some scenarios

Answer 1

If you do validation only in client-side, someone may disable javascript (or change the js code, with firebug, for example). So, all validations made in js would be useless and user can insert invalid data in your system.

Answer 2

Using various tools, such as Fiddler, Noscript, Web Developer, etc., I could disable the client-side javascript validation, and modify the data being sent to your server. Depending on the type of data and what the server does with it, one could initiate a SQL injection attack, attempt to compromise the server security, or simply store bogus data.

A lightweight example: Say you have client-side validation to ensure that a zip code is 5 digits or 5+4 digits. If I disable the client-side script, I could leave my 24-digit value in place. If your server doesn't further check the value, and the database is capable of storing all 24 digits, then I have saved the bogus data.

Answer 3

Actually, there is a huge security advantage to client-side validation (in combination with server-side validation). If you validate carefully on the client, then ALL the traffic coming into the server should be clean. Except for the attackers. That makes it possible to do much better server-side attack detection. In the big scheme of things, that's probably the most important thing that you could possibly do to protect your applications. See the OWASP ESAPI IntrusionDetector or the OWASP AppSensor for more on this.

Oh, and obviously if the attack starts and finishes in the client, like DOM-based XSS, then you're going to have to validate and encode on the client-side.

Answer 4

I assume you're talking about a web scenario?

If you're doing client side validation with Javascript, what happens if the user has Javascript disabled? Then they can submit data to the server that has not been validated.

If they were sneaky, they could even post data directly to your server (bypassing your page completely).

If you do server side validation, in addition to or instead of client side validation, then you have an additional opportunity to defend against these scenarios.

Answer 5

Ideally you'd do both client and server side and never one or the other. If we take at look at these 3 scenarios, both is the only secure, user-friendly way to do it:

Client Side Only: As mentioned, it doesn't take much to get around these validations if somebody wants to send malformed data to your server (such as SQL injection). NoScript won't run the javascript validation code, and some browsers allow the user to actively change all loaded javascript and html, so a user could unhook the validation javascript from the controls.

Server Side Only: This one is more secure than Client-only by a long shot, but cuts back on user friendliness. They have to send their form to the server, have it validated and receive the error page back saying a particular field was invalid. What's annoying is that if any of those fields were password fields, their values are not repopulated by default. For example, lets say the user didn't input a phone number correctly in an account creation form. When the server spits back the page about how the phone number is wrong, the user will see that, correct the phone number and hit submit again, just to receive another error page about not having entered a password (and entering it again in it's second textbox) even though that wasn't the initial problem.

Client and Server Side: You get the security of the server side validation, something the user will be hard-pressed to interfere with, and the user friendliness of input validation without having to submit the page (whether you validate through purely local javascript or AJAX).

If you absolutely had to pick one, server side would be the way to go. But you shouldn't ever have to pick one or the other.