In many cases, I’m afraid the best answer is both.
As Ricebowl stated, never trust the client. However, I feel that it’s almost always a problem if you do trust the client. If your application is worth writing, it’s worth properly securing. If anyone can break it by writing their own client and passing data you don’t expect, that’s a bad thing. For that reason, you need to validate on the server.
Unfortunately if you validate everything on the server, that often leaves the user with a poor user experience. They may fill out a form only to find that a number of things they entered are incorrect. This may have worked for “Internet 1.0”, but people’s expectations are higher on today’s Internet.
This potentially leaves you writing quite a bit of redundant code, and maintaining it in two or more places (some of the definitions such as maximum lengths also need to be maintained in the data tier). For reasonably large applications, I tend to solve this issue using code generation. Personally I use a UML modeling tool (Sparx System’s Enterprise Architect) to model the “input rules” of the system, then make use of partial classes (I’m usually working in .NET) to code generate the validation logic. You can achieve a similar thing by coding your rules in a format such as XML and deriving a number of checks from that XML file (input length, input mask, etc.) on both the client and server tier.
Probably not what you wanted to hear, but if you want to do it right, you need to enforce rules on both tiers.