Why do we need both client side and server side validation? [closed]

Question

One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.

My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.

Tonatonal

This is probably a better fit for Programmers. Voting to migrate. Also potential duplicate: #3484014 – Laoag

In essence there is no such thing as client-side-validation if it is seen as a matter of security. Browsers without JavaScript turned off is likely to kill 95% of all websites on the internet. Almost no website seems to have a fallback for non-javascript browsing. – Complacent

@Allendar: the big websites do. You'd be surprised to know that Facebook (okay. Most of facebook. Some bits don't) works without JS. It's mid-range and "omg web2.0 is awesome" websites that do not... Which is a shame, both for them and for the rest. Nevertheless, some will just never learn :-( – Retroactive

Mandatory XKCD – Zoophilous

Have a look at this. dzyngiri.com/client-side-vs-server-side-validation – Sexist

Answer 1

Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page. If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission. Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.

Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.

What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.

Ludwog

Answer 2

Validation should always be performed server-side - you can never trust client-side validation.

Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.

As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.

Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.

Affront

@Kaushik Well, I usually use TamperData when I'm testing my pages against SQL Injection, I also use Node.js (with form-data module) to generate requests from scratch. In practice, any program can make a http request and send arbitrary GET/POST data - I'm not too sure how that's applicable to a java back-end but it shouldn't be too different. – Fiduciary

Validation can be done on the client, for example many browsers support the HTML5 form validation attributes - html5rocks.com/en/tutorials/forms/constraintvalidation – Wardmote

@Wardmote "Validation" in that sense is merely UX. One can easily bypass that by disabling such constraints through Chrome Dev Tools / Firebug, after all those are nothing but DOM element properties that can be accessed and modified through JavaScript. – Fiduciary

It's called "constraint validation". I was attempting to explain that I thought your statement of "Validation can only be performed server-side" was misleading since the spec. calls it "validation" – Wardmote

@Wardmote Yes I meant it in the sense of validating the input that reaches the server. Will try to reword that. – Fiduciary

@Wardmote And yes you're correct, it is "validation" inside of a browser, thing is (as you know) you don't need a browser and can easily bypass that. Okay, removed the "only" from the first statement. – Fiduciary

Answer 3

Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.

For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.

Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.

Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.

Wardmote

Answer 4

If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:

• User has disabled javascript
• An evil user in purpose has removed the javascript in order to exploit the system
• With javascript validation you reducing the data traffic between the website and the client.
• And of course with server validation you make sure once for all that the data are correct

It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.

Pelayo

Answer 5

Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.

Cheadle