Secure Coding: Principles and Practices

3.4. Bad Practices

Sometimes it's easier for programmers to understand what they need to do if they can see clearly what not to do. The following sections list practices to avoid—security design mistakes we have either seen or, alas, made ourselves. We cover the overall design approach, as well as some specific design flaws.

3.4.1. Beware of Flawed Approaches to Design

The following practices describe common errors that pertain to the overall design approach:

Don't be too specific too soon

One trap that we've seen many application designers fall into is to start selecting specific controls or technologies without first thinking through and making a design—that is, to start coding before knowing what is to be done. Some people seem to want to jump straight from the policy level (e.g., "only authorized users can read our files") to decisions about details (e.g., "we'll use hardware password tokens," or "we'll use that XYZ software that checks passwords to make sure they're 8 characters long"). This is an all-too-easy mistake for engineers, who are problem solvers by nature, to make. Sometimes, it can be hard for us to leave an unsolved problem on the table or whiteboard, and stay at the conceptual level. Resist the temptation to solve that problem as long as you can. For one thing, you may be able to design it away!

Don't think about "what it does"

We alluded to this earlier in our discussion of mental models and metaphors. Many of the strangest vulnerabilities we've seen were ...