"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".

I've never understood "defense in depth" to be in the context of a single application. Rather, an entire network will have "defense in depth" if it has such things as a firewall with proper rules at every gateway, machines with proper virus protection that aren't running silly services, and users with proper responsibility to not run things sent to them via e-mail.

In that context, if a supposed "hacker" wants to gain access to files on machine X, they may be able to penetrate gateway A, router B and firewall C, but they still will be blocked by NIDS D or end up in honeypot E.

The cold, hard truth is: "defense in depth" really means, "don't do anything wrong".

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!

what bothers me most about the PHP community is that it's taken for granted that you should have to do all that yourself from scratch every time.

i think that any php developer who uses any substantial framework would disagree with you.

most PHP developers don't use frameworks. there have been no "substantial frameworks" for nearly all of PHP's history, and the attitude among common users is that PHP isn't responsible for helping you out with security.

it doesn't help that coding style in nearly every PHP book I've seen is insecure and unmaintainable.

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

0) Use a dynamic language with garbage collection.

Are you kidding or referring to a specific such language? I.e., PHP is arguably the most popular such language on the server and it's also the most insecure.

It's even easier to shoot yourself in the foot with compiled languages like C or C++ (strcpy, etc are especially dangerous)

Easier to create problems than in PHP? Naw, just different.

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.