Balancing Mobile App and API Protection

A common discussion that comes up with customers is how they should consider the security requirements of their mobile apps and of the APIs that service them. A recent incident involving Nissan provides a reminder of how easily best laid protections can unravel.

The Nissan case is a simple one where easy access could be gained to one of their Git servers. In this particular case, full source code of their mobile app was available on the server, along with various tools, databases and keys. This is not the first time and it will not be the last that this sort of thing happens. Fundamentally, what it demonstrates is the need to think through all the possible unfortunate things which could happen and ensure that if any of them occur, you are not in a position where your business can be exploited at scale.

Defending Your Mobile App

Ensuring your mobile app is not reverse engineered, tampered with, cloned or repackaged is both important and difficult to achieve. Conceptually however, it seems like a very sensible goal to have. Since you have no control over who downloads your app from the stores and how long they spend studying it, then surely anything which stops bad actors from being able to extract keys or data from your app, or being able to make the app do something different from what was intended is good, right? The short answer is ‘yes’, and the slight longer answer is ‘yes, but…’

The point here is that the enterprise platform is made up of the mobile app, the API(s) that service it and the backend server that executes the transactions initiated by users via their mobile devices. Therefore it isn’t practical, or reasonable, to imagine that protecting the mobile app in turn protects the full platform. So, yes you should put in place defenses in your app - as an absolute minimum code obfuscation should be done - but you need to also protect the rest of your platform.

Defending the APIs that Service Your Mobile App

Although we hear regularly about hacks which occur via tampered mobile apps, many more attacks happen via the APIs. The simple explanation for this is that it’s easier. Let’s not say that hackers are lazy; rather we should categorize them as efficient. Why would you require the mobile app to be in the loop when you carry out an attack, when you can easily impersonate app traffic on the API to gain access to the juicy data on the backend servers?

To be clear, attacks based on fooling a genuine user to use an app which has been modified to be something different from the original version do of course require a mobile app instance to be present, but the vast majority do not, e.g. credential stuffing, DDoS, fake account creation, account takeover, etc. Synthetic traffic, which is extremely difficult to differentiate from genuine API traffic, is so much easier to adjust for different purposes, delivering a broad range of possible exploits from a single starting point. Additionally, it allows the bad actor to modify their approach as you update your security arrangements, for example adjusting transaction frequency to stay below your rate limits.

Therefore, it is vital that your platform security contains a mechanism which can indicate if incoming API requests are coming from genuine mobile apps (good) or scripts/bots (not good). It is also important that this indication is definitive, leaving no possibility of false positives which will impact your genuine customers’ activities.

What Does the Nissan Case Tell Us?

There is no need to pick on Nissan in particular. In fact there was a similar problem with Mercedes Benz a few months ago. However, this isn’t linked to automotive OEMs either - how many times have we read about API keys being left in github repos? Starbucks is one of the more famous ones but there are many, including research projects that scan all github repos.

Now, if you are thinking ‘Ah but we have protocols in place for checking Git server permissions and/or scanning github repos for API keys’ then unfortunately you may be missing the main point here. What is important to understand is that it just isn’t possible to anticipate all the situations your important credentials, code and databases may become accessible. Instead, what you should be thinking is ‘If these keys fall into the wrong hands, how can I ensure that no damage can be done?’. 

In other words, don’t waste time imagining all the possible ways your sensitive data might escape; instead spend that thinking time considering how you can ensure that the data is not usable for at scale nefarious purposes. In the case of API keys, one approach you can take to this is ensuring that a second, independent factor is always needed whenever the key is required to access a backend endpoint, i.e. possession of the API key alone is not sufficient

The Bottom Line

The mobile channel remains the most difficult part of the platform to protect because it contains a remote client that you cannot trust. Moreover, even if you defend the mobile app strongly such that the barrier to tampering is very high, you still can’t relax because you must prepare defenses against situations where credentials and keys may have escaped via other routes.

Defense in depth is a non-negotiable requirement to protect businesses that rely on mobile apps for customers to transact. We’d advise you to defend the app but to defend the API at least as much but probably more. Spend less time checking and double checking that the stable doors are all closed and more time thinking about how you can control where and how far your horse can go if it gets out so you can quickly retrieve it.

Photo by Shiva Smyth from Pexels