It's not all a bed a of roses however. Client-side validation has some minuses too.
You should always validate any fields with requirements on the server. If it's supposed to be a date - make sure it is a date - even if it's passed from your cool little widget as a hidden field. If it is supposed to be a number, make sure it is a number. If it is supposed to be n characters long, make sure it's n characters long. Here are some of the bad validation routines I've seen on the server.
Checking Required Without Trimming - this is an egregious error. Let's say you have a field that is required. Your validation routine makes sure that the user has filled something in before proceeding. Here is what I often see in this case:
Bad Dates - no I'm not talking about last evening. I'm talking about not being careful with the date values that are submitted. One thing that's often forgotten is validating for range. Can someone submit a ridiculous date to your form? Chances are that CF will say "yep, it's date all right", but it will be badly out of range for what is required. For example, if you are collecting date of birth, can someone submit a date of birth that is in future? Also, since most form values are sent to the database, it is always wise to study up on the date "types" that exist on your RDBMS. For example, if you are using MS SQL's smallDateTime data type, you should be aware that the "minimum" date it can hadle is Jan 1, 1753. If need dates before that - you should choose a different data type.
Email Address Validation - it's not "trivial" to check and see if an email exists by querying an exchanger. If your requirements call for that, then it can be done (to a point), but it is not trivial, nor is it 100% reliable (as email "standards" are something of an oxymoron). However, there is NO reason not to validate an email address for format. There are numerous functions that do exactly that. They make sure there is a string followed by an "at" sign ( @ ) followed by 2 strings separated by a dot with the last string being one of the root domains (.com, .net, .org, .gov, .biz etc). That's the least you can do. It's also possible to see if a domain exists - and it is pretty trivial to do that on a CFMX server, though it may be something of a performance drain if you are doing it constantly, because it uses Java networking classes. Cflib.org has this excellent UDF that will handle it for you.
Database Scrubbing - probaly 90% of what is submitted via forms goes into a database somewhere, yet it surprising how often form variables are passed "as is" into a CFQUERY tag. There are lots of obvious reasons to use CFQUERYPARAM tag, but preventing malicious SQL injection attacks is perhaps the most important - especially when handling form data.
Hey - if you have a tip for server side validation that you want to add to this post - please do!