Top Tips for Secure App Development
You don't have to look far to find examples of security breaches involving critical enterprise information or private customer data. In the IT world, protecting these assets is often discussed in terms of functions added to network perimeters or remote computing devices. In fact, many of these security systems are attempting to compensate for invitations to theft in the form of badly designed and executed applications. Developing safe applications will make every security function more effective and in some cases, create some redundancies.
There are five key operational areas to be aware of and two important techniques for greater overall security. Let's start with the five key areas to keep in mind when developing secure applications.
Who gets to use the application? If the answer is "anyone," then there are significant security problems in place before the first line of code is written. Ensure that the users must identify themselves in a secure fashion, and you've made a good start. The arguments over single-factor versus two- or three-factor authentication are far less important than simply requiring some form of authentication to use the application.
What can legitimate users do with the application? Does every user get to change information? Can every user display the entire contents of the database? Once you've positively identified the users, you must then make sure that they only have access to those pieces of information they require, and then only perform those operations that legitimately pertain to their jobs.
How are you protecting the data when it's in the database? Is the application's connection to the database secure? Is the data encrypted while it's resting peacefully on the server? How about while it's in the network link between the application server and client? There's no excuse for not protecting data in transit by encrypting it, and the growing number of large-scale data breaches demands that encryption should become common policy for data sitting in storage, as well.
What happens if someone enters SQL commands where his or her name should go? Can someone reach through the application that appears on their screen to touch another application in the environment? Testing each point of entry for type correctness and filtering out all nonappropriate characters will put real limits on what a malicious user can do to you through the application.
Logging and auditing
If a theft occurs from a database and no one can prove it happened, is it no big deal? Of course it's a big deal and proving what happened is critical for mitigation, restoration and prosecution. Here's a tip: Make sure the limits on log-file sizes are three to four times bigger than you think they should be. The extra size will come in handy. Really.
And then there are two things that will make a huge difference when it comes to securing the issues just mentioned.
Test, Test, Test
Don’t just test for functionality — get someone who knows what they're doing to try to break into the application. Try again. And again. There's no guarantee that you'll find every possible security hole (in fact, in a complex application it's closer to a guarantee that you won't), but you will find many of the problems and be able to fix them before they get into the wild.
Use a Framework
So many problems occur just because different members of a team use their own personal methods for securing applications and definitions of what security even means. A common framework, used by every developer, will help make sure that team members are at least speaking the same language when it comes time to build security into the app.
Building security in from the beginning is cheaper, more effective and less disruptive than trying to bolt it on after the fact.
Cover the bases using the right techniques, and you're most of the way to preventing massive data breaches before the first cup of programmer juice gets cold.