Why don’t developers write secure code ? We’re not talking yet another time about _“clean code” _here. We’re talking about something more, on a pure practical perspective, software’s safety and security. Yes, because an insecure software is pretty much useless. Let’s see what does insecure software mean
- The European Space Agency’s Ariane 5 Flight 501 was destroyed 40 seconds after takeoff (June 4, 1996). The US$1 billion prototype rocket self-destructed due to a bug in the on-board guidance software
- A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of X-rays
- The software error of a MIM-104 Patriot, caused its system clock to drift by one third of a second over a period of one hundred hours — resulting in failure to locate and intercept an incoming missile. The Iraqi missile impacted in a military compound in Dhahran, Saudi Arabia (February 25, 1991), killing 28 Americans
This should be enough to understand how important it’s to write secure and working software, specially in certain contexts. But also in other use cases, we should be aware where our software bugs can lead us to.
A first sight to Defensive Programming
Why do I think Defensive Programming is a good approach to issue these problems in certain kind of projects?
Defend against the impossible, because the impossible will happen.
There are many definitions for Defensive Programming, it also depends on the level of “security” and level of resources you need for your software projects.
Defensive programming_ is a form of defensive design_ intended to ensure the continuing function of a piece of software_ under unforeseen circumstances. Defensive programming practices are often used where high availability, safety or security is needed — Wikipedia_
I personally believe this approach to be suitable when you’re dealing with a big, long-lived project where many people are involved. Also for instance, with an open source project that requires a lot of extensive maintenance.
Let’s explore some of my diluted key points in order to achieve a Defensive Programming approach
Never trust user input
Assume always you’re going to receive something you don’t expect. This should be your approach as a defensive programmer, against user input, or in general things coming into your system. That’s because as we said we can expect the unexpected. Try to be as strict as possible. Assert that your input values are what you expect.
The best defense is a good offense
Do whitelists not blacklists, for example when validating an image extension, don’t check for the invalid types but check for the valid types, excluding all the rest. In PHP however you also have an infinite number of open source validation libraries to make your job easier.
The best defense is a good offense. Be strict
Use database abstraction
The first of **OWASP Top 10 Security Vulnerabilities** is Injection. That means someone (a lot of people out there) is yet not using secure tools to query their databases. Please use Database Abstraction packages and libraries. In PHP you can use PDO to ensure basic injection protection.