There is one rule you should be aware of from the get-go that will save you a lot of pain (and potentially legal liability in the worst case):
Nothing the client ever sends you should ever be trusted, full stop. No argument, no exceptions.
There is also an important corollary to this that you should keep in mind:
Everything the client can see is fair game to someone who wants to abuse your system.
The more visibility the client has into how things work, the more likely it is that someone can do something they shouldn't. (I am not advocating "security by obscurity" here - just pointing out that giving control to the client is a liability.)
By the same token, the more responsibility the client has, the more likely it is that someone can do something they shouldn't. You should always aim to design these sorts of things to where the client has a minimum of information and a minimum of responsibility.
SQL injection is a classic example of what can go wrong if you forget these two rules. It's just the beginning, though, and defending against it is actually notoriously hard to get right. (I actually recommend using parameterized SQL and ideally something like stored procedures, instead of constructing SQL from strings, because of this.)