Secure coding - tips, tools and principles

Secure coding - tips, tools and principles

March 05th, 2014 By: Stefan von Gagern
When people think of secure coding, they often think of things like SLL first. While this is not wrong per se, many simple, basic principles that can prevent later problems are often ignored. We provide tips and demonstrate practical tools.
Secure coding - tips, tools and principles

Security must be embedded in the entire development process, best of all from the start. (Credit: © venimo -

Apple recently published a security update for iOS and OS X that seemed to be a routine patch at first, but then turned out to be a serious security flaw. Hackers could exploit this vulnerability, known as "goto fail", to launch attacks on encrypted SSL connections in the same network, and in the worst case intercept sensitive information sent during chat, e-mail and online banking sessions. The flaw has now been corrected by a patch.

Like other security problems in the past, "goto fail" is likely due to one of the usual software vulnerabilities, such as gaps in the code, errors or logical weaknesses – which attackers can exploit. The silver lining to this cloud: nearly all vulnerabilities have things in common.

After conducting an analysis of thousands of software vulnerabilities, security experts have discovered that most gaps are repetitive and actually originate from a manageable number of software errors. These, in turn, often result from incorrect programming practices. These findings formed the basic idea of "secure coding": by focusing on insecure practices and urging developers to use safer alternatives, teams can actively help prevent vulnerabilities from arising prior to deployment. We have compiled several useful tips about what secure coding means in practice.

The right start: ask questions

Regardless of whether you are starting a project from scratch or need to update an existing program: the first step toward developing secure software is to ask yourself simple questions. For example, what effects a vulnerability could have on the software or what the worst case might be. Detailed examples:

Questions about potential risks:

  • What could go wrong?
  • What do we need to protect?
  • Who could try to attack our system?
  • Where is our weak point?

Questions about resources:

  • Which guidelines and standards can help us?
  • Which good role models can we use as inspiration?
  • Is there a security concept (internal or external) that we can already use? Is it already being used?

Questions about the software:

  • Who will have access to the software, source code and program?
  • What happens if the number of users increased rapidly?
  • In which environment will the software run (for example, in the web or in a closed company system)?

(Of course, each project has its own reasonable questions. These examples merely provide a few directions the questions might take.)

From day one to "safe error"

Bug fixes and security patches often only become necessary because essential gaps were overlooked at the last minute. It is much effective to avoid vulnerabilities from the start whenever possible.
For example, it is useful when the roadmap for an application includes information as to how encryption will be used during data transmission. In general, when designing an application, you should always think of the worst possible attack you can imagine. That may sound paranoid, but if you always keep potential opponents and attacks in mind, you will become more cautious in many steps – for example, when it comes to granting permissions.

In addition to attacks, you also have to take errors into account. Every system and every application can crash, but the crucial thing is what happens when a crash takes place. Example: If the firewall fails at a company, the network should be closed off instead of being defenseless. Therefore, the target is a "safe error". In many cases, it is not easy to decide on the most secure scenario, for example, whether an app needs to be shut down completely.

Make the foundation and the environment safe

There are already reliable solutions to many problems, so why should developers have to reinvent the wheel? Sections of source code are reused in every project, whether as open source, components or something similar. While open source can pose a vulnerability itself, it also lets developers draw on secure frameworks, cooperative coding projects, books and articles that help build a secure foundation for the software.

Moreover, out-of-the-box development environments are available – for example, specifically for mobile app development, where security has top priority. Developer Garden powered IBM Worklight is a cloud-based development platform that has a wide range of features for authentication and preventing unauthorized access to applications and processes. Secure login modules are just one example. The app back ends can also be run in Deutsche Telekom's secure data centers, if desired

Test without getting tired of testing

The highly recommended book "Secure Coding: Principles and Practices", which is available to read online for free at Google Books, contains a wise statement about testing by Brian W. Kernighan and Rob Pike:

“It's tedious and unreliable to do much testing by hand; proper testing involves lots of test, lots of input, and lots of comparisons of outputs. Testing should therefore be done by programs, which don't get tired or careless.”

Therefore, automated testing represents an effective solution. The book recommends testing according to a defined schedule, of all components at every stage of the development process, and according to defined processes. A broad range of programming languages (including .NET, ASP, VB, Java, C/C+, PHP, Ruby, Perl and JavaScript) can be subjected to static code analysis.

One example of such a tool is the Developer Garden Code Analyzer. This virtual compiler lets you scan non-compiled code automatically, regardless of programming language or project stage. The first 30 days are free of charge, including 3 scans with up to 50,000 lines of source code each.

About the author
About the author

Stefan von Gagern works as a freelance journalist in Hamburg. Since 10 years he covers web and mobile technologies and –development. He also works as a consultant, helping companies to build websites, mobile and social media. At Kiel university of applied sciences he teaches media conception. In his free time the gadget fan loves to write music as a singer/guitar player in bands and his home studio.

Contact: Homepage | Twitter