Top 10 Secure Coding Practices

"The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn't stake my life on it."

(the original version of this is attributed to Gene Spafford)

I'm going to point out that in practice, #8 (Practice Defense in Depth) rarely works.

The reason is simple: it's Hard to bulletproof any one security control, and the cost of getting controls even slightly wrong is the same as not doing it at all.

It can be tricky to come up with an example of a system that met a real-world security requirement only because a stack of security controls held together despite breaks the individual controls. Windows XP SP2 is a famous anti-example. Secure runtime: good! Security development lifecycle: better! Memory corruption vulnerability: often still game-over!

For assessors of applications (I'm one), the words "defense in depth" are usually blood in the water. It's code for, "we made a bunch of assumptions here, but that's OK because use modsecurity".

Unfortunately something as simple as input validation often does not occur. It baffles me when I look over at code from contract work or I come into a new job and see GET requests modifying the database, and POST's going completely unchecked. Madness!

I'm surprised there aren't any good comments about the photo.

0) Use a dynamic language with garbage collection.

I think that #4 - "Keep it simple" is such a key part of creating secure applications. I think that as software is modified and grows and expands and more people touch the source we add in complexity that often blows away the security of the software. We need to make sure that we consistently apply our security conscious programming skills throughout the entire project.