Larry Hipp / Development / January 2nd, 2014

Security Lessons Learned From SnapchatDB

New Years Eve is a celebrated occasion for many around the world. The night is filled with parties, champagne, singing Auld Lang Syne and looking forward to what a new year can bring.  While we were all getting ready for the ball to drop in New York, a group of hackers decided to ring in the new year early and spoiled the party for our friends over at Snapchat.

Shortly before midnight I saw a tweet about a website ( claiming to have released private information for more than 4.6 million Snapchat users. We’ve seen plenty of “someone got hacked”  tweets that turned out to be a hoax so I was skeptical, but curious.

Snapchatdb (which has since been removed) was a simple site with extremely easy methods of accessing the data. A click of a button would retrieve you a CSV or SQL file of everyone’s data. The site was overrun and timing out after a few minutes, so it’s doubtful many people were able to access the data right away. Unfortunately, the Internet never sleeps, and the data has since been mirrored on servers around the world.


The files contain the username, city and a masked phone number for 4.6 million users! The hackers claim they will continue to mask the last two digits of each phone number to protect the innocent, but lament the fact that Snapchat had ample time to patch the exploit and seeks to hold  those we trust with our data accountable. While the leak may seem like a questionable course of action for noble hackers, Snapchat was allegedly warned about the security hole months ago but did not move to fully secure user data.

Snapchat’s data getting hacked is an unfortunate example of what can happen if security is not Priority One for software. User experience, SEO and features may be what capture your audience, but a security breach can send your customers running away faster than they ran towards you.

With large-scale hacks becoming more commonplace (iPhone hack details, Twitter Hacked), it’s easy to feel overwhelmed and as if security is a lost cause. While no one can guarantee 100 percent security there are some things you can start doing right now to take steps to securing your software and your user data.

SSL everything

Forcing your website and APIs to use HTTPS is a great first step towards a secure environment. HTTP allows sensitive information to be transferred in plain text across the internet, so anyone with the capabilities to listen to your traffic can, theoretically, read all your data. There are some sophisticated ways to compromise HTTPS, but it’s by far the easiest first step in securing your data and protecting  your customers.

Data encryption

Storing data is a requirement for most software to provide value to the user. In our industry we can’t avoid storing data, but we can assess and mitigate the risk associated with each data point we store. Encrypting sensitive information stored in your database can protect you from data leaking from your secure environment.

Due to its mobile nature, the Snapchat app is centered around phone numbers, which you may not necessarily classify as sensitive all on its own. However, when combined with a username the two become very descriptive of an individual user. Classifying individual data points or combinations of data as sensitive and encrypting those in your database can be very effective.

Beware of unauthenticated data access

APIs have exploded in the world of software over the last 5 years. APIs can provide a very RESTful way for software to consume data, but they can be a security risk if they aren’t built with a thoughtful plan. Unauthenticated access to an API should only return public information. Some of the most common hacks over the last few years have come from APIs that return private data. If your developers can figure out how to extract data from your APIs, so can someone from the outside looking in. Remember that security by obscurity is not security at all.

Friendly error messages

Error messages that return system error codes or information from the server can give away valuable peices of information that can be used to find a weakness in the system. Error messages should always be scrubbed before being displayed to the user to show a friendly message. Often, developers return information to the client to better understand communication during the development process. Having a strong QA process in place is critical to catching any error messages before they make it to a production environment.

Filtered client-side responses

As we move towards more and more client-side data rendering, we must be critical of what data is sent from the server. It’s not safe to send an entire data record from an AJAX call. For example, if we are editing a user’s information from a form with AJAX, it would be expected that we make a request to populate the form with the data we have already stored. Our datastore may have lots of data stored about this user (unique id, encrypted password, last know ip address, credit card information, etc.), but you only need to send the client what it needs and nothing else. If we were to send the user’s entire record to the client this data is now stored in the browser.

While your average user isn’t aware of this and doesn’t know where to find it, web developers around the world know, and it’s all there is plain text (unless you have taken steps to encrypt your data).

It’s great if you’re already doing these things! However, we must stay vigilant in the protection of our data. All aspects of your security policy should be continually tested to ensure new software entering the environment hasn’t introduced a new exploitable point in the system.

Our users trust us with their data everyday and it’s our job to ensure we secure their data with the highest degree of protections. Snapchat’s user database leaking is an example of how a simple security vulnerability can expose an entire database along with millions of users’ data in the process.

Image credit: Nick Carter