I know a lot of forms out there that will accept any input. The standard to improve upon here is often rock bottom.

A lot of developers do not know that data should be validated.

The point isn't that you shouldn't validate data. It's that telling developers to validate data doesn't help them. It begs the question of "how" to validate data, and the answer to that question is so big that it encompasses most of software security. Meanwhile, left to their own devices after that one instruction, developers come up with silly input validation schemes, like password fields that don't accept SQL metacharacters.

While hard to apply, the correct answer is pretty obvious: identify the invariants of your system, and make sure your inputs abide those invariants. To do this, there are two complementary approaches: you can parse your input into something intelligible and safe for your system, or you can reject invalid input.

The hard part is identifying the invariants of your system. But (and I know I'll sound like Dijkstra), that hard part is also the minimum bar. If you don't know what it takes for your system to behave correctly, how can you hope to build a correct (and therefore secure) system to begin with?

Some people love to say "don't roll your own crypto", with the strong implication that whoever is trying to it is not competent enough. Well, the same applies to any server exposed to the internet, any moderately interactive website, any network library, any video decoder, any compiler… all those things have the potential to go catastrophically wrong in the face of hostile input, and therefore should be held to similarly high standards.

Here's my advice:

1. Make sure you understand invariants, and why they matter.

2. If you don't, train yourself. It may take years.

3. Validate your inputs (but you already know that by now).

Not helpful? Sorry pal, programming takes time to learn, and I don't have the time to teach.