How to Keep Your Mobile App Secure

Published on December 4, 2019

Security is a hot topic in the world of technology, and a question we often get is: Can my app be hacked? The short answer is: yes. Your app can be hacked.

If your app is useful at all, then there is likely a way to get data into and out of it. Just like the door to a room, if anyone can get to it, then in theory, a hacker can find their way in as well.

But just like doors in real life, there are several ways to prevent the wrong people from walking into it. You can shut the door, put a lock on it, put a deadbolt on it, buy a stronger door, hire an armed guard to stand in front of the door, put a bunch of laser-activated alarm systems around it... you get the gist.

Similarly, your app needs to have a strategy around how to keep its data safe. Not every system makes sense for every app, but every app can stand to do a few basic things to keep the information in ship shape.

We put together a list of things you and your development team can do to make your app less interesting to a hacker, along with steps to take if your app does get hacked.

Listen to our podcast episode on this topic:

10 Ways to Secure Your App

1. Make security a priority from Day 1.
2. Encrypt everything.
3. Sanitize and filter user content.
4. Use unique passwords everywhere.
5. Use IP whitelisting.
6. Use 3rd party dependencies sparingly.
7. Implement system frameworks.
8. Think like an attacker with white hat hackers.
9. Keep your system up to date.
10. Train your team to be aware of social engineering.

Make security a priority from Day 1

According to IBM’s annual report on data breaches, the average cost of a data breach in the U.S. for 2019 was 8.19 million dollars, up nearly 4% from 2018, with the cost impact in the United States higher than anywhere else in the world.

You can download IBM’s report and filter it by industry and region to learn about the potential impact of a data breach on your company.

These staggering numbers are enough to convince anyone of the importance of considering security from the very first stages of app development. When hiring your development team, there is a lot to consider, and your team’s focus on security should be front and center with your app’s design, development, features, and support all incorporating talks around security.

Encrypt everything

Your development team should be encrypting all your data, whether it is at rest on a user’s device or in transit to your server.

What is encryption? A scene from A Christmas Story illustrates encryption on a very basic level. Ralphie’s favorite radio show gives out secret messages that can only be decoded with a special decoder pen. These encrypted messages are essentially what encryption is: taking a message you want to send and obscuring it so someone else cannot understand it without the right key.

So what gets encrypted? Basically, everything: passwords, credit card numbers, sensitive information, any data required by law.

As we said above, encryption is dealt with both while data is moving between the server and the app as well as when it reaches its destination.

If you are transmitting data between an app and a server, it must be encrypted using SSL. This is better known as HTTPS, which shows up as that green lock icon in your address bar. Apple requires apps to use HTTPS, so your development team should be using this already.

When data is at rest on your device or on the server, there are a few ways you can encrypt the information. One of your best lines of defense is to store tokens that represent values instead of the values themselves.

Let’s take credit card numbers. Let’s say that a user’s credit card number is 4242 4242 4242 4242, with an expiration date of 12/20 and a CVC of 315.

If you were to store that information in plain text on your device and experienced a breach, you would not only be giving a hacker the keys to your customer’s bank, you’d also be quickly introduced to the consequences administered by a fun friend of ours called PCI DSS.

We use Stripe whenever we incorporate credit card processing for this exact reason. When a user gives us their credit card information, we immediately give that info to Stripe. They, in turn, send us back a token that looks like this: tok_1FlipVBSZq5Qg1JDCuTwmEJO.

Whenever we want to use that card in the future to run a transaction, we just tell Stripe to use that token. They are able to look it up on their end, make sure it’s attached to a valid credit card, and we’re good to go.

You can apply a similar technique when you’re dealing with signing in a user. Instead of saving a user’s email and password in plain text on your device, you can send that information to a server who would send back a token that represents that user. When you ask for more data in the future, you can just send that token to prove you are who they thought you were.

Filter and sanitize user-generated data

Any area where users enter data are one of the easiest places for a hacker to find back-door access into an app. Things like sign up pages and uploading profile pictures are ripe spots for would-be hackers to find holes in your system.

Think back to our analogy above about doors: if a user can use these places to put data into your app, then a hacker might use those same places to make the hole a little bigger for themselves.

A good development team will filter these areas to make sure the information being provided is valid. This can be done by doing things like validating email addresses or requiring specific file types in upload sections (like JPG or PNG for a profile picture).

In addition to filtering data, we also need to sanitize it. Ne'er-do-wells may try to put code in these areas that will try to pry the door open (or at least cause a ton of damage to your system).

We can catch a lot of these data sanitization issues by using industry-standard frameworks. These frameworks are designed by default to prevent these attacks from happening, so in addition to getting your app built more quickly, using a framework like Ruby on Rails or Django will allow you to get a step up in your security game.

Use unique passwords everywhere

We’re sure you’re already using a unique password on every site you use, but just in case, let’s briefly go over why poor passwords are bad.

If you use an email and password on a poorly-protected site and that site gets hacked, a hacker could take that email/password and try it out on common sites like Facebook, Gmail or your bank. If you’ve used the same email/password on all of these sites, a hacker now owns your digital life.

As an app owner, if you have a dashboard where you are a super admin and can edit users, you definitely need a unique username/password, or else the same rules apply as above.

To keep your users even more safe, you should also require users use combinations of numbers, letters, and symbols for their passwords, that they change their password every certain number of months, and/or add two-factor authentication.

Two-factor authentication checks two sources to verify you are who you say you are typically by (1) entering your password and (2) entering a special code sent to your phone or email address.

Pro tip: Tools like 1password or LastPass generate (and remember) unique passwords for every site you use.

Use IP whitelisting for anyone accessing your app’s dashboard

All computers connected to the Internet are assigned an IP address, usually at the router level.

Your development team can set up your system so that it only allows users in who come from certain IP addresses. A good place to implement this functionality is at your admin dashboard. This verifies that the only people accessing your app’s dashboard are those with known and validated IP addresses.

Use third party dependencies sparingly

We like to say that all software is built on the shoulders of giants. Some of these “giants” come in the form of dependencies that are really important, like the software that lets you create a connection to your server.

Some of these dependencies, however, might not be as important, like the Google or Facebook SDK.

When considering dependencies to use in your app, make sure you are using open source dependencies wherever you can. This ensures developers can see exactly what is being done with the data by looking at the code.

The software that lets you create a connection to your server is likely open source. The Facebook and Google SDKs are not open source. If you plug in Facebook’s SDK for, say, marketing purposes, you have no idea what they’re doing with the data they collect.

If something is closed source, it doesn’t mean you can’t or shouldn’t use it. It just means you need to do an extra level of vetting to make sure it isn’t introducing a hole that a hacker can exploit later or taking the data and transmitting it to their systems where they can do whatever they want with it.

Use system frameworks properly

Apple and Google provide system frameworks for code to be written against, and most reputable development shops will write their code to interact directly with those frameworks.

Sometimes, though, it may be easier for developers to use a third-party framework to do a task.

One of these tasks is commonly around the world of networking. Frameworks like AlamoFire and Retrofit make network calls a lot easier to write. These frameworks are well-vetted and use the SSL (encryption) library provided by Apple and Google.

However, some developers might use a different library that doesn’t use the standard SSL library. This could lead to security issues down the road because while AlamoFire and Retrofit have a strong community who keeps their system up to date, a lesser used framework might not.

Make sure your team is using popular, well-vetted frameworks when needed, and make sure their code is using as much of the tooling provided by Apple and Google as they can.

Hire white hat hackers

Black hat hackers are the bad guys you see in movies, sitting in a dark corner, stealing data.

White hat hackers are people intentionally hired to try to break into an app and steal data in order to expose the app’s insecurities.

Hiring a white hat hacker could be useful to keep your system up to date and test the security features your team has already created.

They aren’t particularly cheap, but hiring a white hat hacker to find these holes is a whole lot cheaper than losing the data to a black hat hacker.

Keep your system up to date

Keeping your system up to date with the latest security vulnerability fixes is absolutely critical.

A great example of why you should keep your system up to date is Wordpress. Because Wordpress powers 30% of the Internet, it is constantly being fished out for holes and vulnerabilities.

Hackers will run scripts to find back doors into sites that are running older versions of Wordpress. If they get access, they can destroy the database and hold the site ransom.

The best way to prevent against this is not only keeping the Wordpress core itself up to date but also the underlying technologies that power Wordpress, like Linux, Apache, MySQL, and PHP (LAMP, as us nerds call it). This same principle applies to mobile apps. You want to work with a development team who keeps its system up to date and continually ensures your app is compatible with the newest versions of iOS and Android to prevent any open holes into your servers.

Train your team to be aware of social engineering

Social engineering is a term that describes how users can be manipulated into giving up their personal information.

Social engineering is how many hacks occur today. They happen in many ways, including phone calls from “their bank” or emails from “their friend”.

While it is important to keep your users safe from social engineering attacks, it’s doubly important to train your team on how to keep their own accounts safe. After all, if someone can gain access to your employee’s accounts, that can spell disaster for everybody.

---

What to do if you’ve been hacked

Up to this point we’ve outlined steps you and your development team can take to prevent a hack by making sure your app is secure as possible. But security is a cat and mouse game, and sometimes the cat (or is it the mouse?) wins.

When you’ve been hacked, you need to get in person with your development team and outline your plan for containing the breach. Here are the steps you should go through:

1. Calm down.

As with any disaster situation, your emotions are going to be high and your adrenaline will be maxed out. Find a way to calm down so you can think with a clear head.

The last thing you want to do now is have a melt down. You need to lead your team through this process, so take care of yourself.

2. Contain the breach.

Find out where the hackers got in and close that hole. This might be a lengthy process, so get started right away.

3. Figure out the damage that was done.

Good developers will have already installed logs to track what happens in the backend. Comb through these logs to see what the hacker accessed.

One pro tip here: give your developers time to do their research. They are going to be stressed out as well, and having someone breathing down their neck will not help them go faster. Agree on a few check-in times throughout the day (I would say every other hour in the initial stages, and dial it back as you can) and assume when they are not talking to you that they are working on their task.

4. Clean up the mess.

The approach you take here is very dependent on the type of breach you incurred.

If a hacker’s intent was to destroy all of your data, you should restore the data from backups.

If their intent was to steal information, you need to communicate the losses right away (more on that later).

Some hackers might have been in your system for a long period of time, so be sure you are thorough in cleaning up your mess. A common approach hackers take is to leave backdoors for themselves to get back in later, so be sure you take care of those doors.

5. Get a plan in place to prevent the hack from happening again.

Most hacks happen through a vulnerability that you can plan for. You need to know where the app’s security fell down.

Were your backups not checked regularly? Were your developers not testing your code for holes or updating your frameworks? Do you need to hire a white hat hacker? Did your staff fall prey to social engineering?

Regardless of where the vulnerability is, you want to make sure you don’t fall victim to that approach going forward. Come up with a plan to plug that hole so it does not happen again.

6. Notify your customers.

Depending on your situation, notifying customers may be the first thing you do. Not only is it the right thing to do, often times, it’s the law.

Our advice is to be as transparent as possible, especially when it comes to users’ private data. Tell them what steps you took to fix the problem and what steps you are taking to make sure it doesn’t happen again.

You may want to consult with a disaster recovery firm to craft your message. Do your homework now and establish a relationship with someone who can help you if disaster does strike.

---

As we mentioned before, security is a never-ending game of cat and mouse, and it is important to do the fundamentals correctly to reduce your chances of a breach.

The biggest thing you as an app owner can do is to create a culture of security within your development processes. Encourage your team to be proactive in fixing potential vulnerabilities and executing on the basics of keeping data safe.

At the end of the day, you want to make sure as your theoretical “house” grows, the “door” to get in needs to be kept up to date as well. You might not need the lasers guarding your data at this point, but as you grow, keep an eye on security and make sure you are doing everything you can to prevent a disaster.