How to avoid the top 10 software security flaws

Half of the software-related security defects that provide entry to threat agents aren’t bugs found in code; rather, they’re flaws embedded in software design. The IEEE Center for Secure Design brought together some of the foremost experts in software security in a working group to tackle the issue of secure software design.

Based on their findings, here are 10 powerful do’s and don’ts examining the most common software security flaws.

• Do make sure all data from an untrusted client are validated.
• Do assume data are compromised.
• Don’t use authorization, access control, policy enforcement, and use of sensitive data in client code.

• Do prevent users from changing identity without re-authentication after they’re authenticated.
• Do consider the strengths of the user’s provided authentication before taking action.
• Do make use of timeouts.
• Don’t stray past the big three: something you know, something you have, and something you are
• Don’t share resources like IP numbers and MAC addresses.
• Don’t use predictable tokens.

• Do perform authorization as an explicit check.
• Do reuse common infrastructure for conducting authorization checks.
• Don’t forget that authorization depends on the context of the request, not just a given set of privileges.

• Do utilize hardware capabilities to enforce separation of code and data.
• Do know and use appropriate compiler/linker security flags.
• Do expose methods or endpoints that consume structured types.
• Don’t co-mingle data and control instructions in a single entity.
• Don’t use APIs prone to injection such as XSS, SQL injection, and shell injection.
• Don’t use (eval).

• Do ensure that comprehensive data validation actually takes place.
• Do use whitelisting.
• Do use a centralized validation mechanism and canonical data forms.
• Do make security review of the validation scheme possible.
• Don’t make assumptions about data.
• Don’t use blacklisting.
• Don’t use strings.

• Do use standard algorithms and libraries.
• Do centralize and reuse.
• Do design for crypto agility.
• Do get help from real experts.
• Don’t roll your own crypto. It’s too hard to get it right.
• Don’t ignore key management issues.
• Don’t implement nonrandom “randomness.”

• Do know where your sensitive data are.
• Do classify your data into categories.
• Do consider data controls such as file, memory, and database protection.
• Do plan for change over time.
• Don’t forget that data sensitivity is often context-sensitive.
• Don’t mistake confidentiality for data protection.
• Don’t ignore trust boundaries.

• Do think about deployment, configuration, use, and updates.
• Do know that security is an emergent property of the system.
• Do consider user culture, experience, biases, etc.
• Do make things secure by default.
• Don’t treat security as a feature.
• Don’t impose too much security.
• Don’t assume users care about security.
• Don’t let users make security decisions.

• Do test your components for security.
• Do include external components and dependencies in review.
• Do isolate components.
• Do keep an eye out for public security information about components.
• Don’t forget that composition is dangerous.
• Don’t underestimate the amount of security risk that can be inherited.
• Don’t assume open source is secure.
• Don’t trust until you have applied and reviewed controls.