Coding like Kung Fu
A high level overview of Defensive Programming
How many hacks or epic software failures in history could have been avoided? Are software vulnerabilities mostly a matter of hardware faults or software inefficiencies? How can I define a secure program? Are program failures predictable as edge cases evolve?
These were some of the questions that inspired me to search for a high level view of defensive programming. I figured, the answers to the questions above can lead to better nights of sleep for software developers and owners alike.
As defined by Wikipedia, defensive programming is “ a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances”.
Informally, I’ve found definitions such as, “ defensive programming is when the programmer makes necessary assumptions and creates code that anticipates potential problems and specification changes”.
As with all things that are broad there is a degree of subjectiveness to the views of what actually composes the subject. This vast domain is hotly debated amongst cyber security enthusiasts, researchers and newbies like me who have interest in a rapidly evolving field of large problems & lucrative opportunities.
“Distrust and caution are the parents of security.” — Benjamin Franklin
Many view defensive programming as a matter of time, either as a time waster or something they do not have enough time for. I hypothesize that these thoughts may be the culprits behind many costly errors and exploitations. Here are a few examples of very bad things that may have been avoided using a defensive programming thought process:
Through my review I have discovered that defensive thought processes give a program many different “abilities” that provide a sense of security against random events. These include:
- Testability
- Maintainability
- Portability
- Supportability
- Deployability
Most importantly, when using defensive coding principles we stand to improve our code’s comprehensibility and position our systems to perform predictably despite unknown risks from inputs or users.
As for Kung fu, well, defensive programming may be similar in many more ways than I know of, but it surely shares commonality in the fact that Cyber Security is as diverse of a subject as Martial Arts.
While researching, I decided to create a map of the concepts I felt really stuck out as the core elements of defensive programming . It is my goal to explore these concepts further throughout my education and software career.
I’ve recently began my defensive programming journey by utilizing validations and unit testing. Validations in particular presents a unique thought exercise that forces me to contemplate security and user experience in unison. This is a lot of fun as I see it as a way to truly build cool things for an end user. This happens all while I am thinking of all the ways to break what I am building. At times it seems like it makes no sense, but be reminded of the events above.
Specifically, validations vet user inputs before they are committed or persisted to our data storage systems. Validations can happen at various levels of software and hardware.
As for web applications using the MVC framework, validations can typically be stored in the model, controllers, views and database itself. These varying levels of validation presents many opportunities to not be a lazy developer and keep the “abilities” of our software in optimal state.
In the end, I hope to practice, learn and implement enough on my defensive programming journey to rival the challenges of the ever evolving human & digital worlds. I personally find software architecture principles, methods to validate and test my systems very interesting. Then again, who am I?
