Simplifying app security: Getting started

Not all apps are created equal in terms of security – and even big-name brands can be open to attack.

In 2016, Uber reported that hackers stole the information of over 57 million riders and drivers. And less than a year ago, Under Armor’s MyFitnessPal was hacked, affecting 150 million users.

Breaches in security don’t just mean company app’s though – in their annual report, Cisco found that 31% of organizations have experienced cyber attacks on operational tech infrastructure.

But what does a cyber-attack look like?

It can take many forms; cyber criminals could inject harmful malware, tamper with your app’s code, intercept sensitive information and steal customer data, or compromise your network and get hold of critical intellectual property.

But where can hackers gain entry?

Where is data most vulnerable?

From a developer’s perspective, there are three stages to describe where your data is:

1. At rest and out of your control – data that’s stored on the app

2. In transit – data that’s moving between the app and an external location like a server

3. At rest and under your control – data stored on the server

When you save data on your server, you “own” the location it’s stored in, so you can be confident in its security.

But when you save information on the app, it’s on the user’s personal device – they can potentially do whatever they like with it.

Storing sensitive data on an app should only ever be done when absolutely necessary, as it’s the most easily accessible point of entry for a hacker. It’s far safer to keep information on the server where it can be stored securely, and only pass it to the app when required.

Compromising style for app security

One of the issues with this approach is that it compromises how user-friendly your app is. For example, let’s look at the difference between screen refreshing with a banking app, and a social platform like Facebook.

With a banking app, users expect that a period of inactivity will mean they have to log in multiple times and go through various security checks. But with an app like Facebook, users don’t want to have to log in every time they go back into the app.

App security features are entirely dependent on the app itself though – it’s a constant balancing act between a great user experience and top data protection.

So – we know app security is crucial, but what can be done to ensure information is protected?

In the rest of this series, we’ll cover the key steps to help you control every other technical aspect of security.

And we’re starting internally…

Internal policy importance

As many as a third of companies don’t have a written security policy, but it should be a critical part of your business, let alone your app.

You need to look at your current internal policies when it comes to the security and privacy of your customer data, technological infrastructure and so on.

• What privacy policies are in place?

• What confidentiality agreements do you have with customers about how you’ll use and protect their data?

• Understand the complexity behind GDPR and how it applies to you and the platforms that make up your offering

• Are there any industry bodies you answer to?

• What regulatory requirements are there with the technology you want to build?

These are all vital considerations for your internal team – once you know the answers, you can brief your developers and find out how you can ensure these commitments are met. It will affect the functionality of your app and where your data is best stored and accessed.

They’ll then be able to build a reviewing process into your development schedule, to ensure that whatever technology you use (or create), it conforms to all these policies you’ve discussed.

Something else to keep in mind at this stage is whether there’ll be any collaborative working involved.

For example, if your app needs to pull through ads for revenue, it’s likely there will be another server from a communications company that needs to be factored in. What are theirprivacy policies and security procedures?

Always assume that anything coming into your app is a threat until you verify otherwise – ensure your development team are communicating with any third parties right from the off so that security is made a priority.

The next blog in this series will cover building a secure code base and back-end network, but for now, why not take a look at our other recent piece about security and privacy in the realm of voice technology.