Is your code S.A.F.E?

The website Information Is Beautiful has an illuminating chart for the World's Biggest Data Breaches. Not only does it show that breaches have become more common in recent years, but also that many of these breaches were insider jobs. Hacking has become an industry in its own right and, if you're a software developer, security should be your concern. This is particularly true in the world of distributed software where your environment is often not entirely under your control and should not be blindly trusted. You need to ask yourself: is my code is S.A.F.E?

S : Sensitive

Sensitive code looks after its sensitive data (passwords, application secrets, client personal detail, session tokens, ...) This means:

• Not storing application secrets in version control unless there is tight access-control over the repository. Ideally, move secrets to secure servers, and even more ideally, move secrets into a password manager like HashiCorp's Vault.
• Encrypting sensitive data in transit and at rest.
• Not logging sensitive data, particularly if you have a log aggregator that makes this data visible to potentially unauthorised individuals within the company.

A : Access-controlled

Whenever your sensitive code is remotely accessed, you need to authenticate and authorise the request, i.e.

• Who is the caller?
• Are they allowed to do this?
• Are they allowed to do this on this particular data?

You need to log requests for auditing purposes, in particular, authentication or authorisation failures.

In addition, consider zoning your network so that not everybody can reach your sensitive services.

F : Foolproof

Do you validate your requests?

It's good defensive programming practice to validate your inputs, but this is particularly true in the world of JavaScript and SQL injection attacks.

Prefer strong-types to strings. If you must use strings, prefer whitelisting to blacklisting checks (today's evil character set might not be tomorrow's).

Fail securely.

When returning errors, don't reveal details of your system's inner workings that a hacker could use (e.g. stack traces or overly specific error messages like "password incorrect" instead of "login failed").

E : Enforced

You don't know your code is secure unless you've checked that it is. This means:

• Threat-modeling your design.
• Adding security checks to your code-reviews.
• Automating your security checks via tests.

Be SAFE. It's dangerous out there.

P.S. If you want to learn more about application security best-practices, check out the OWASP website.