[tenebrisalietum]

- Validate ALL data that comes from external sources, even if you think it could not possibly be changed unexpectedly. External sources includes things like user input, configration and session files, and even things like dynamic libraries if you care enough.

- Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time.

- If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers.

- Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that.

- Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public.

- Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions.

The above is a good percentage of it I think.

[tptacek]

Telling people to "validate all data" is like telling them "not to have security bugs". It's not helpful advice. Validate for what? Length? SQL metacharacters? Javascript notation? HTML? Authentication? Concurrent submission? The list of things to consider is essentially a list of practically all vulnerabilities.

[MattGaiser]

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.

[tptacek]

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.

[loup-vaillant]

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.