Why do we need server side as well as client side validation for Web applications?_问答_开发者

Is there any high level reason to have both client side and server side val开发者_开发百科idations for a web application ?

Because your client side validation may be subverted.

For example - on the web, if you are using javascript for validation, it is very easy to either turn javascript off, or change how it works using tools such as FireBug.

Event with other client/server methods, it is possible for the data link to be subverted and the "validated" data can be changed on the way to the server (Man In The Middle attack).

In general, the maxim "never trust the client" is the reason that you need to always validate on the server.

You may ask in that case, why validate on the client? In order to provide immediate feedback.

User can modify the validation javascript locally (save the page and do anything with it) or javascript can be turned off in browser. So in this case client-side validation is useless. Hence, you should verify on server too

Client Side Validation is used for the following
1) conformation of data to length and format constraints
2) instant indication or feedback to the user

Server Side Validation
1) more advanced validations against business logic
2) check for any changes in criterion. for example you order a book from amazon and after just when you checkout you get an indication that the book is out of stock because someone else would have purchased it just moments before
3) Check if the intended user has posted the data. Client side stuff like cookies and javascript can be manipulated hence the server does need to authenticate and taint check the data coming through.

Thus server side validation is required as the primary line of defense against malicious data and also for checking the data against advanced business logic.

Client-side validation gives the user immediate feedback without having to wait for the page to load. However if the client has disabled client-side scripts (e.g. JavaScript disabled), the validation won't fire which is why you need the server to check the values as well.

Client side will remove (in theory) the majority of validation issues before reaching the server (though this is not always the case when JavaScript is disabled/edited etc). This will remove any 'strain'/unnecessary processing from the server by placing the onus on the client device to perform validation.

Server side will catch any validation issues that, for some reason, were not caught by the client side validation.

Client side validation is a plus, but not necessary. You MUST use server side validation (ssv) because when you're accepting user information, you should always treat is as "hostile". If that data also gets fed into a database, ssv is your last line of defense because you don't want junk or invalid data in your database.

Client side validation is not bullet proof, and therefore if something gets validated on client side, that doesn't mean it'll be valid when it arrives to your server.

The purpose of real-time client-side validation (i.e. as the user moves from field to field rather than after the user hits SUBMIT) is to give the user feedback ASAP. If the Social Security number, for example, requires 9 digits, and the user has typed 8, you don't want to wait until the user has completed the rest of the form and hit SUBMIT to point out the error, even if the validation occurs client-side. Waiting until after SUBMIT to validate client-side is nearly pointless--all it does is spare your server and your bandwidth. Pointing out errors as they are made usually results in a higher rate of form completion because it is a simpler experience overall for the user -- there won't be a list of errors: "Please correct all of the errors below". But you still need to have server-side validation to ensure data integrity in any case. The night club bouncer stands in front of the club door not in the parking lot across the street.

If you have an application with several tables in the database, your server-side validation might be just a set of the restrictions (the part of your data table design). We may think that we do not have any validation on a server side though, because it is not a middle-server layer, but a DB layer restrictions.

Then we may say, having advantage of relational database - based on Integrity (we know that our data structure is safe). In most cases we may use only client side validation to provide a client an instance feedback to his actions. It might be not a critical issue not to have additional validation in server side layer, in controllers on in any server side code.

Thus we may say that for some/most cases we may use only client side validation. Server side validation is - special case like: to check if something was already bought, when client submits a purchase form.

That is not bad idea to not repeat yourself with validation on both sides.

Of course there are applications that require a lot of attentions to their data, then not only server side validation is important (like part of business model safety but test coverage for most use cases - for client's input.

But if it is just a site with several forms... Then I believe database restrictions and client side validation is good choice.