client side Vs server side validation....

Just wanted to know peoples opinions on client side versus server side validation for forms etc...

I personally use client side all the time for simple things like checking for input etc.... it saves time for the user and resources on the server.....

the reason I ask, is some of my mates prefer server side... so they allow the user to submit the details, then send them back saying "sorry, you must complete X, Y and Z".... I hate that....

What does everyone else use??

If you're talking about web applications, then client-side provides no security. If you want to use client side validation, that's kewl (i use it for checking form completeness, email validation, and some other simple things), but you then have to do it again on the server side.

The reason is because there is nothing stopping someone re-creating a form from your site, removing the validation, then posting it to your post-back script. Attempting to verify where the form is being posted from doesn't help either, cos it's easily spoofed.

hmm.... I never really thought of that. Yeah, I meant validation in web applications. I never thought of someone simply re creating the form to get in the DB..... this is actually a problem for me, which I need to go and address right away!!


Cheers for the advice! oh god, I'm scared now........

stumpy,

i'm curious as to the legalities of that... i read articles on how apparently some shopping cart applications are still using a simple GET method when submitting forms, obviously making it easy for any user to manipulate the send string and change any data they want... the article also mentioned that the certain site in question sent the price (determined by a hidden field in the html form) as a part of the GET string... obviously a super-poor method of operating a shopping cart... [i'm starting to ramble]

anyways, apparently the legalities come down to the fact that its up to the company to confirm the order... and if you don't validate on the server side and simply confirm the order you could run into some major problems...

uh, i guess my point was... ALWAYS server side validate... and it is a great idea to client-side validate as well, to cut back the load on the server [less bounce backs]

Hmm - yeah, the legalities of sending out a product where the prices have been altered by the consumer... interesting.

Something kinda similar happened recently on Amazon where a worker there accidently entered a wrong price for an IPAQ (i think it was something like $20AU) - apparently a contract is in place and finalised once the consumer has the product in their hands... so, unless the vendor manually checks the price, there mightn't be much they can do....

the amazon gaffe: http://www.theregister.co.uk/content/54/29828.html

yea client side validate for form completion and the like

but when actually doing something functional and important.. do it in both places... so you know there is no messups

One thing that hasn't been mentioned, although it's obvious, is the fact that many people disable Javascript... So if you're only doing client-side validation, good luck!

Your best bet is to do both CS and SS, although I prefer Server Side.

now that should be a poll topic.. kinda like how many people have the flash plugin.. how many people have javascript turned off...

Are you volunteering boo?

I use both CS and SS checking, as people have already mentioned js can be turned off, etc. CS serves as an early warning mechinism for the user. I then also check SS, I also ensure that the previous page was the form, using the referer variable in php.

Also as a security tip, you should always use switches as much as possible instead of if() and else

as you can catch anything thats wrong, more easily (well i do atleast)

Also as another security point, most forms should be POST and not GET, like im stating the obvious

at the very least you should always do SS, as it cant be fudged

Just on the POST/GET thing... there is no real difference between the two. You should never pass any sensitive data around in the client. Using POST offers no more security than GET does.

A secure site uses sessions and validates ALL data, server-side.

This is interesting stumpy.. can u explain a little bit more? Because I have always thought that using POST is more secure because variables could not be manipulated so easily... so.. how is it not secure? Just want to get a clearer understanding because this question has always been playing in my head.



I agree with this one... I have always used SS for validation and my principle is to use minimum CS as much as possible... and most of the time I don't at all. A little bit more work.... but I could ensure that it works across a variety of browsers.

That's a great method for security check... but recently, I was browsing through the PHP manual and here's what it says:



What does that mean exactly? When it says 'User Agent', does it mean the user's browser or something that is set on our side? How could we make sure that this is works well ?

Thanks!

A 'user agent' is the browser (or whatever ever the user is using to view your site).

Re: security - post vs. get - basically there's no difference in security in using either method. Anyone can see the values you submit in your form (view source!). Point is, never pass sensitive info in forms - it should all be handled server-side.

Checking for referrer URL is not secure (tho people use it in situations where security isn't an issue). This is easily spoofed. Run a packet sniffer on your modem and look @ what actually occurs when you request and receive a web page. You will notice the first few packets which establish the HTTP connection to the site are all in plain text. All these values can be created manually by the user if they wish (thru socket programming).

I'm not an expert on form security, but I do use them at my job - I do the client side, someone else does the server side.

Client side validation - good to make sure form is filled out correctly before submitting - i.e. <form... onSubmit="validate(); return false;">. People can turn JavaScript off to get around this. People can copy your HTML (generated) source, modify it, and submit it (I've even used that technique at work to get a couple things done for customers)...

Server side- be sure safe and proper information is submitted

You can check the URL the form is being posted from for security, but that can be faked... You can create a session variable ($SESSION['form_pass'] = "845y3ngf9";// I think... in PHP... I know ASP better...) but even THAT can be faked. Person goes to your site - session variable is set, person goes to their spoofed form with no session interuption, person submits form - session variable still in tact. Even THAT can be faked.

The ABSOLUTE best way to ensure that the form is being submitted from YOUR site is to use a security image ("Type the text you see in this image... etc") as in forms located here: http://www.networksolutions.com/en_US/whois/index.jhtml And I don't know how that works...

Security images are quite simple to do. Simply obtain a component that can produce an image on the fly. Feed it some characters to insert into the image, and store those chars in a session.

When the form is submitted - check the user has returned those chars - match against what you have in your session.

Note that this alone does not ensure that the form is completed on the server either. Security images are only used to ensure that a human completed the form, and not a bot/script.