The Burden of Data Security
Security in web based applications is one of the most widely discussed and important topics in modern application development. With the increasingly strong ties between our daily lives and technology, the stakes for keeping sensitive information out of the wrong hands have never been greater. People now take it as a matter of course that their social security numbers, bank accounts and private conversations are the kinds of things that can safely be transacted via the internet. This assumption puts the burden of data security squarely on the shoulders of developers.
In this post, I won’t be going too deeply into any specific threats or methods to avoid them. Rather, I will be providing a few general tips and considerations to keep in mind as a software developer.
There are two major considerations when assessing how you should respond to a vulnerability in your system: how likely is it that it can be exploited, and how bad are the potential consequences? If a threat is particularly likely to be exploited but carries very light consequences, it might not merit as much attention as other, more consequential ones. These are judgment calls that you will have to make.
Build with Security Considerations in Mind from the Ground Up
One way to avoid finding yourself in a situation where a large, scary security hole threatens your application is to build your application with security in mind from day one. It’s easy to fall into the trap of thinking “This will never be widely used enough for it to matter” or “The software couldn’t possibly grow to incorporate access to sensitive information.” But the reality is that you don’t know for sure. Additionally, it is not the case that having access to sensitive information is the only reason hackers attempt to access systems. There are numerous reasons why simply being able to use someone else’s system for one’s own ends is attractive; carrying out illegal activities being just one example. Others simply want to cause chaos for the sake of it.
Never Assume Your Software Will Only Be Used for Its Intended Purpose
Hackers are creative and imaginative. Where you look at a website and see it as a source of information, they see the possibilities it provides to wreak havoc. It is your job to see your software in the very same light. Ask yourself: “What is the most insane outlandish possible use of my software that I can imagine?” and then assume that someone somewhere will think the same. You know your software better than anyone, so you are ideally suited to think of all the ways it could be misused. It might also be the case that you are so accustomed to seeing it a certain way that it is hard to escape that vantage point. For this reason, always question every assumption you make in the development process.
Use Libraries to Accomplish Sensitive Tasks Where Possible
Libraries are pre-made coding tools used to simplify otherwise difficult tasks. Large, well established, well vetted and widely used libraries and frameworks are some of your best lines of defense against security threats, as they exist solely for the purpose of handling certain kinds of tasks, and are made by people who are well versed in the area.
Implement a Thorough Code Review/QA Process
When building an application and working hard to get it out the door, it’s easy to get tunnel vision and omit important, but time consuming processes in the name of expediency. This is not advisable. Code is complex and even the most seasoned developers will overlook seemingly minor things that could create serious security holes. Mandatory code reviews as well as a dedicated QA team to go over changes with a fine tooth comb are essential to minimizing security threats.
Penetration testing (or “pen testing”) is the process of having someone adept at finding security holes attack your system for the purpose of giving you a chance to fix any discovered issues. There are two different fundamental types of pen testing: black box and white box. The “black” in black box implies that the tester is not given information about the internals of your system (e.g. source code), while “white” implies the opposite. Here at iGrafx, a recent penetration test concluded that no major vulnerabilities exist in our software. This is something tangible that we can offer to our customers as proof that their data is secure.
Be Aware of Common Security Standards
This post has merely scratched the surface of important security practices. As there is an abundance of information available regarding best security practices, it might be hard to know where to start looking. When it comes to widely accepted standards, two of the best sources are the Open Web Application Security Project (OWASP) and Common Weakness Enumeration (CWE). While OWASP provides general information about best practices, CWE is geared more directly at developers specifically. I encourage those who feel like these considerations might apply to them to investigate further. The safety and security of your software as well as your users might depend on it.