"A man with some evil design, would he not be likely to speak well of that stupidity which was blind to his depravity, and malign that intelligence from which it might not be hidden? Not unlikely, perhaps."

— Melville

Secure Web Applications

When I started in web development, if the truth be told, we didn't take application security very seriously. At first (this was 1997) there were simply no 'known issues', because everything was still new - it was amazing enough that things worked! We got a little high on our ability to make remarkable things happen on the server. What security concerns we had, we consigned to the realm of the administrators.

Things are much different now. Successful web security begins with the layered application of network security, server security and application security. For the programmer, application security is now a central architectural concern.

In today's web environment, webmasters, systems administrators and application developers share interlocking and overlapping security responsibilities.

The programmer's responsibilities begin with the incoming HTTP packet, overlapping there with the responsibilities of the network administrator. They extend into the gateways to various subsystems, such as database servers, where they overlap the responsibilities of the database administrator. The programmer is responsible for everything in between, yet even here his security responsibilities overlap with those of the server adminstrator and the webmaster who must keep their system software up to date and patched as necessary.

These overlapping responsibilities are an opportunity for layered defence, not for dereliction of duty! The database administrator applies restrictive permissions to the database tables, assuming that the programmer may slip up and allow rogue queries to execute via SQL injection. The programmer assumes that there are no defences at all at the database level and that he must protect the database subsystem himself by passing only carefully checked and sanitized queries. Because each takes full responsibility, the subsystem achieves a double layer of protection.

In all languages and environments, we work within a flexible, evolving framework of loosely-coupled functional modules, fully tested and debugged. Defenses against known attacks, such as cross-site scripting, SQL injection and handcrafted requests, are incorporated into these modules. Additional reusable modules are expressly designed to defend against specific attacks: for example, session hijacking and login replays.