Software Integrity Blog

How to avoid the top 10 software security flaws

Half of all software security defects aren’t bugs; they’re design flaws. Here are 64 do’s and don’ts to help you avoid the most common 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.

1. Earn or give trust, but never assume it.

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.

2. Use an authentication mechanism that can’t be bypassed.

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 are

Something you have

Something you know

Don’t share resources like IP numbers and MAC addresses.

Don’t use predictable tokens.

3. Authorize after you authenticate.

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.

4. Strictly separate data and control instructions, and never process control instructions received from untrusted sources.

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).

5. Define an approach that ensures all data are explicitly validated.

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.

6. Use cryptography correctly.

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.”

7. Identify sensitive data and how they should be handled.

Do know where your sensitive data are.

Do classify your data into categories.

Do consider data controls such as file, memory, and database protection.