Simplifying app security: build a secure codebase

Leaky apps that have a badly-written code can release customer data without the user ever knowing, but there are things we can do to build a secure codebase.

It starts with your development team.

First, find out whether they’re using third party code from elsewhere. Could it have been corrupted somewhere? If an app has any complex elements to it that require lengthy code, it’s not unusual for developers to use third party libraries.

These libraries have a variety of benefits to them, like the ability to copy reams of code that would normally take a developer hours or days to write. This saves them a huge amount of time and money (which they can pass on to you, the client).

There are plenty of secure libraries out there (most of which are licensed so you can use them with attribution), but some developers might not have such stringent guidelines – it’s always worth checking where the code was written and whether you can trust it.

Encryption and tokenisation

Next, let’s look at your data.

This can be protected through encryption, so that anyone intercepting it won’t be able to read it. You should use HTTPS where possible when connecting to a server – it will ensure that all communication between the client and the server is encrypted.

Then, to further reduce the exposure of sensitive data to risk, you should use tokenisation.

With tokenisation, the server issues the client with a token that can be used to represent sensitive data. If the connection between the client and the server is compromised, the token is discarded and a new one issued as soon as a secure connection is re-established.

Developers can also use obfuscation, which essentially scrambles your code – particularly useful with Android apps, which are predominantly written in Java and easy to reverse engineer.

Build a secure codebase, but don’t forget your back-end!

Your average mobile device connects to around 160 unique IP addresses every day – aside from your codebase, you need to pay attention to your database, server and other back-end security.

It’s possible to encrypt databases and connections using HTTPS; for mobile databases where information needs to be stored locally, these platforms offer an encrypted SQLite module to ensure its safety when at rest on a device.

But how does a server know that you are who you say you are when transmitting data? By putting the right authentication measures in place.

OAuth2 is an agreed standard for authorisations, and developers use this protocol for managing secure connections via user-specific, one-time tokens.

Permissions can be granted between the client and end users by collecting credentials. There’s an OAuth2-based standard designed for mobile apps too called OpenID Connect, which your developers should be using.

One issue is that in a secure system these tokens should expire quickly, which would normally require re-authorisation. This is where refresh tokens come in; these tokens can renew every few minutes, so if someone tries to steal your data in that time they’ll only have access for a very short period.

Using third parties for testing

Finally, you build a secure codebase and back-end, you’ll need to conduct thorough testing.

While you can test the app in different environments in-house, you won’t truly understand the extent of any flaws unless you use penetration testing.

This is where testers try and break your code, putting it through a variety of scenarios, and report back using vulnerability assessments on where you could improve.

This is essential to your security and must be conducted by a third party – it’s the best way to catch anything you might have missed through human error.

The next blog in this series how to decide on the right security measures for your app, from biometric identification, to pinning and tap-jacking.