What we can learn from our mistakes
The full CWE/SANS list is detailed, comprehensive, eminently readable, and chock-full of specific, valuable advice. If you manage a software development project, you'd be well served to pass the link along to everyone on your team and encourage them to study it in depth. Even a cursory read, however, yields key insights that every developer should keep in mind.
First, know your tools, and don't accept their features blindly. Among the specific recommendations given in the CWE/SANS list are such gems as "If you are using PHP, configure your application so that it does not use register_globals." This particular advice is as old as the hills, and it has actually been the default configuration since PHP 4.2. As of PHP 5.3, the feature in question has been deprecated. Developers who persist in using risky platform features because they're there, despite countless recommendations to the contrary, deserve what they get.
Second, don't put too much faith in your platform just because it's said to be more secure. For example, managed languages such as Java and C# eliminate the possibility of buffer overruns by doing bounds-checking at runtime. That means Java and C# programmers are shielded from the third-ranked error on the CWE/SANS list. But neither Java nor C# does anything to protect you from SQL-injection vulnerabilities caused by poorly validated user input, which rank even higher on the list than buffer overruns. Any platform is only as secure as the code that runs on it.
Third, data security is hard. Unless you're a specialist, cryptography seems like an arcane art, and it's tempting just to treat it simply as magic dust that you can sprinkle onto your applications to make them more secure. Similarly, it's all too easy to introduce backdoors in your authentication scheme if you don't treat security as a core principle in your software design process. Improper, inconsistent, or naïve application of security techniques is especially insidious because it fosters a false sense of safety even as it leads to serious vulnerabilities.
Last, and most important, the list reminds us that software vulnerabilities are everywhere, and virtually no development project is completely safe. With the pace of Internet attacks accelerating, now is not the time to cut QA staff or skimp on testing and code review. No matter what tools you choose, developing secure applications is challenging and laborious, yet critically important, now more than ever. Let's be careful out there.
This article, "Developer error: The most dangerous programming mistakes," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.