Why is client-side validation not enough?

Question

I saw here that:

As you probably already know, relying on client-side validation alone is a very bad idea. Always perform appropriate server-side validation as well.

Could you explain why server-side validation is a must?

Dayfly

Consider client-side validation as a convenience that you provide your users. Server-side validation is where you actually do the the validation. – Jujutsu

It might be worth your reading through some of the answers offered on this SO topic: #1727117 – Generalist

In one sentence: Don't trust the client. Why? Because you can't. – Dux

Client-Side Enforcement of Server-Side Security is one of common software weaknesses cwe.mitre.org/data/definitions/602.html – Selfrising

security.stackexchange.com/a/175472/96753 – Lewanna

Answer 1

Client-side validation - I assume you are talking about web pages here - relies on JavaScript.

JavaScript powered validation can be turned off in the user's browser, fail due to a scripting error, or be maliciously circumvented without much effort.

Also, the whole process of form submission can be faked.

Therefore, there is never a guarantee that what arrives server side, is clean and safe data.

Polished

It applies to everything having a client, for example online games, and so, as said by @Pascal, you can't trust the client. And, in the case of webpages, they are the easiest to fake =/ – Susan

Answer 2

There is a simple rule in writing server application: Never trust the user data.

You need to always assume that a malicious user accesses your server in a way you didn't intend (e.g. in this case via a manual query via curl instead of the intended web page). For example, if your web page tries to filter out SQL commands an attacker already has a good hint that it might be a good attack vector to pass input with SQL commands.

Outfox

Answer 3

anyone who knows basic javascript can get around client side.

client side is just used to improve the user experience (no need to reload page to validate)

Wychelm

Answer 4

The client you're talking to may not be the client you think you're talking to, so it may be ignoring whatever validation you're asking it to do.

In the web context, it's not only possible that a user could have javascript disabled in their browser, but there's also the possibility that you may not be talking to a browser at all - you could be getting a form submission from a bot which is POSTing to your submission URL without ever having seen the form at all.

In the broader context, you could be dealing with a hacked client which is sending data that the real client never would (e.g., aim-bots for FPS games) or possibly even a completely custom client created by someone who reverse-engineered your wire protocol which knows nothing about any validation you're expecting it to perform.

Peewee

Answer 5

Without being specific to Javascript and web clients and to address the issue more widely, the server should be responsible for maintaining its own data (in conjunction with underlying databases).

In a client-server environment the server should be ready for the fact that many different client implementations could be talking to it. Consider a trade-entry system. Clients could be GUIs (e.g. trade entry sysems) and (say) data upload clients (loading multiple trades from .csv files).

Client validation may be performed in many different ways, and not all correctly. Consequently the server shouldn't necessarily trust the client data and perform integrity checks and validation itself.

Moises

Answer 6

In case the attackers post their own form.

Contrite

Answer 7

You can turn off/edit JavaScript.

Commixture

Answer 8

Because the user agent (e.g. browser) might be a fake. It is very easy to create a custom application to create an HTTP request with arbitrary headers and content. It can even say it is a real browser—you have no way of telling the difference.

All you can do is look at the content of the request, and if you don't check it you don't know it is valid.

Brigittebriley

You can also check session variables—not just content. – Lewanna

Answer 9

Server-side validation is a must because client-side validation does not ensure not-validated data will arrive in the server.

Client-side validation is not enough because its scope of action is very restrict. The validation is performed in the browser user-interface only.

A web server "listens" to and receives an HTTP request containing data from the browser, and then process it.

A malicious user can send malicious HTTP requests by many ways. A browser is not even required.

The client-side validation, performed using JavaScript, in the browser, is an important usability, user-interface enhancement. But it does not prevent malicious data to be sent by an user that knows how to circumvent the browser default behaviour of building the HTTP request that will be sent to the server. This can be done easily with some browser plugins, using cURL, etc.

Loiseloiter

Answer 10

In general, it's best for EVERY piece of an app to do it's own checking/verifications.

Client-side checks are good for maximizing the user-experience and speeding up the feedback to the client that they need to fix something, and to reduce the amount of problems encountered in the server-side checks.

Then at each major point of transition on the server-side code, you should have checks in place there too. Verify inputs within the application code, preferably via whitelist input validation, and then have any interactions with the database use parameterized queries to further ensure problems do not occur.

Kee

Answer 11

You should perform server-side validation on any data which, if invalid, could be harmful to anyone other than the entity posting the data. Client-side validation may be suitable in cases where invalid data would have no ill effects for anyone other than the entity posting it. Unless you can be certain that the ill effects from bad data will not spread beyond the entity posting it, you should use server-side validation to protect yourself against vandals or other rogue clients.

Chancellorsville

You need to validate it even if it would only harm the submitter, due to the possibility of cross-site request forgery attacks. en.wikipedia.org/wiki/Cross-site_request_forgery – Peewee

@Dave Sherohman: Thanks for the correction, though I'm not sure I understand it. If a rogue user agent submits bogus information which has no effect other than to return bogus data to the rogue user agent, how will that enable the attack? Who is assumed to trust who, and what mischief will be allowed to happen that the rogue user agent couldn't do itself? – Chancellorsville

Imagine a rouge agent constructs an invalid query, and entices the target to execute that query, perhaps through a hidden iframe The bogus response will be from your domain, with access to your applications cookies, for example. If the bogus responce allowed the injection of client side code, the attacker could steal the cookies and subsequently launch further attacks with this new information. – Papageno

@Douglas: I'm unclear who plays what roles in your example. Are you suggesting the response to the query will go to someone other than the rogue agent that sent it? If so, that would violate the "have no ill effects on anyone other than the entity posting it" condition. Basically, I was thinking of situations where a bogus input might cause some code to output data which was meaningless. For example, an anagram solver might client-side restrict the input to letters and blanks, but on server-side might simply fail to find anagrams for inputs containing other characters. – Chancellorsville

Sorry, the example wasn't particularly clear (it brings up issues which should be handled by proper output escaping, rather than input validation). The point I'm trying to get at is that the person who constructed the malicious query might not be the person who executes the malicious query, so you still have to play safe. A recent example of someone messing about along these lines: giorgiosironi.blogspot.com/2010/08/… The attacker sought to make negative press for Google by distributing a malicious query for others to execute. – Papageno

@Douglas, that's an interesting read, but I fail to see how it's relevant here. If the invalid data is only harmful to the entity posting the data, but someone dupes a lot of people into posting that same invalid data...how, exactly, is server-side validation supposed to prevent that? – Lewanna

@Wildcard: I think I see what the Douglas is getting at, but his follow-up example was poor. A better issue might be with sites that construct client-side Javascript based upon submitted data. If submission of deliberately-malformed data could cause the server to send harmful code to the client, the server should perform sufficient validation to guard against that even if the effects of the code would only be harmful to the client. – Chancellorsville

Answer 12

Client sided validation is for saving the client from entering wrong data. Server sided validation is for saving the server from processing wrong data. In the process, it also introduces some security into the submission process.

Buber

Answer 13

Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser. The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.

Timework

Answer 14

Buddy , Suppose if a person turnsoff the javascript in his browser , the validation became dead . Then if he post some malcious content through that form to the server side . It will lead to serious vulnerabilities like sql injection or xss or any other type of problems . So beware if you are going to implement a client side javascript validation .

Thank you

Ubangi