Don't Be a LinkedIn: Security Best Practices for Startups!

Here are some basic security measures that all products should implement.

1. Treat all user input with suspicion

When you're designing your app - be it a webapp or a mobile app, you should treat all user-input fields as potentially dangerous. For example, in your webapp, if you're accepting an address field, you'll need to put in a check to ensure what is typed into that textbox is only an address. And not some funky Javascript or SQL commands that a hacker has pasted into the field. And if you insert that malicious script into your database thinking that it's just an address, you may end up compromising your app and database.

To protect against these kinds of attacks, you should always "clean" all user-input fields. Escape all HTML and Javascript tags. Depending on what programming language you are using for your app, there are standard libraries that can do this.

2. Never store passwords in your database

Under no circumstances, should you ever ever store user's passwords in cleartext in the database. In your USER tables in your database, you always store only the hashed password. And for your hashing algorithm, use something new like the "SHA-256" algorithms, and not MD5 or SHA-1, which have already been compromised.

However, the biggest security risk with passwords usually is that your users will pick very bad passwords. "password", "1234", "test123" etcetera are all very common passwords, and you really can't protect against that. One way you can improve security a little bit, though, is by "salting" passwords. This technique involves adding a random string to the user's password, then hashing that combined string and storing the hash in the database. You add the same "salt" string when the user is logging in, hash the result, and check if the hash matches what is stored in the database. This way, you can verify the user entered the right password, without storing the actual password anywhere. For example, if the user's password is "password", behind the scenes you turn it into "78Xu4d_password", hash that, and store the hash in the database.

While this won't prevent your users from picking weak passwords, even if your passwords are somehow leaked, recovering the user's original password from the hash will be hard, and the hacker will be left with some useless junk strings.

3. Always stay updated!

Security is a cat-and-mouse game between the good guys and the bad guys. Software vulnerabilities are regularly discovered, and also regularly patched in updated versions of software. You have to ensure that whatever versions of software you have installed on your server, they always remain up-to-date. Wordpress, Apache and even your Operating System has to be updated on a regular basis. Without the latest patches installed on your server, there will be a known way for a hacker to break into your app. Once a skilled hacker discovers an older version of some software on your server, it becomes trivial for them to just look up the documented vulnerabilities in the version of software you are running and break in.

Keeping up with all the versions of the software on your server can be a bit hard, but you can have a process around it. Maybe once a month, do a "security audit", where you upgrade and test all the software you are running.

4. Backup, but more importantly Restore!

Nobody is immune from server downtime, not even Google. In Feb of last year, a bug in Gmail caused a widespread outage and even data loss for a few users. Now you would expect Gmail to have backups of the data, and Google did have the backups. But when they tried to restore from the backups, they realized that the backups were on tape drives, offsite. So when Gmail had to be restored for these users, it involved driving over the backup tapes from across town, and painfully restoring all the data by hand. Gmail had to restore some 200TB of data, and that obviously took some time, and all the while Gmail was down for those users.

The moral of this story is that it is not just sufficient to backup your data, but also important that you be able to restore the data. The worst situation is when you have an incomplete backup, and you don't realize it until after it is too late. Maybe you're missing a configuration directory in your backup or maybe some metadata is missing. While it is great practice to backup regularly, you should also restore regularly, just to ensure that your backups are complete, and in an emergency, you can be confident that you'll be able to get your app up and running after the restore.

These are just some starting points. As you scale your app, you will need to pay proportionately increasing amounts of attention to security as well. It's not a particularly difficult or painful job, it's just that you have to ensure that you do it and have a process around it.

Find more about server security and security resource articles here.