Safeguard your code: 17 security tips for developers

Infoworld - The scary stories from the Web are getting worse. First there were a few stolen credit card numbers. Then there were a few thousand. Now we hear about millions of financial records being exposed by security breaches, and we grow numb to the potential threat. Credit card numbers barely scratch the surface of what the bad guys are after, and there are more dangerous stories that come out of the labs studying cyber war.

Writing secure code begins long before the first loop is formed -- and is no easy task. To even approximate bulletproof code, architects, engineers, auditors, and managers must try to imagine everything that could go wrong with every aspect of the code. Although it's impossible to anticipate every nasty curve the attackers will throw, you have to do all you can to reduce your attack surface, plug holes, and guard against the fallout of a potential breach.

Here are 17 tips for producing more secure code. The list is far from complete, but it should bring you closer to your goal. Feel free to share your insights for developing secure code in the comments below. We all benefit from greater security.

Secure programming tip No. 1: Test inputs rigorously

Attackers need a path into your machines, and the easiest routes are through the doors your code opens. If your software takes input from the Internet, someone will try to sneak something past you.

The classic example is the buffer overflow created by lazy C programmers who accept any string of characters until that string hits the number zero, the official C symbol for the last character. Attackers discovered long ago that they could send arbitrarily long packets of data and write over the programming stack and the memory as long as they never sent that terminating zero. If they were clever with what they wrote, they could assume control and rewrite anything.

Another classic attack on open doors is SQL injection. That Web form may just ask for your ZIP code, then dutifully paste these few characters into an SQL query, but clever hackers started adding extra characters that expanded the scope to be more than a simple search. When the software blithely grabbed all the input, it ended up feeding the SQL directly to the database.

The solution is to test the size and structure of the incoming data and never, ever trust the person on the other end of the Internet.

In general, programmers want to offer more flexibility and less enforcement. Checking every last bit of data is time consuming for the software and exhausting for the programmer. Data transport languages like XML and JSON don't do much to ensure that the data avoids these problems. But checking is what the programmers need to do to secure their code.