In a previous article, we discussed “When do we add security into our app and onto our APIs?” The conclusion was to do it as soon as possible! That said, there are still choices to be made so in this article we explore how you should decide on appropriate protections for your mobile app and APIs.
When discussing when to build security into a mobile centric platform, it became clear that there are very good reasons to include it as early as possible. This allows you to focus on feature development and minimizes the risk that unplanned security events require diversion of your valuable technical resources to deal with them, derailing your plans for market domination.
When considering mobile apps and APIs, many security options exist and so it is important to logically work through the most appropriate ones for your use cases.
The first step is to consider what threats you are most concerned about. Threats should not be prioritized based on the probability of a particular attack happening but rather on the impact that attack would have on your business if it did happen.
For example, if you left a coat in the back of your car, it’s possible that someone might see the coat, break into your car and steal it. That would be annoying and inconvenient, but it would not stop you from carrying out your plans for that day. Conversely, if the car was stolen, that could prevent you from completing essential tasks such as attending a business meeting or visiting someone important. Therefore, although having a coat stolen might be more likely than losing a car, protection against car theft should be a higher priority. Once that is achieved, consideration should then be given to how to prevent items being stolen from the car - or even better - making sure they are not left in the car in the first place!
In order to see how this applies to mobile app and API security, let’s consider the 3 main components in the mobile platform and what options we have to protect them.
Mobile apps are attacked for these primary reasons:
It’s important to note that most of the reasons that bad actors attack mobile apps relate to extraction of data or intelligence that enables subsequent attacks against the whole platform. The primary vector used in those later cases is a script which impersonates genuine mobile app traffic. We’ll return to this topic later.
A number of security approaches are available to protect your mobile app code:
More information is available on the broad topics of in-app protection and mobile app shielding.
APIs that service mobile apps are attacked mainly to intercept and/or modify the data which is transmitted on them. Intercepted traffic is examined to understand the API protocol being used, and perhaps the relationship between actions in the mobile app and the resulting API transactions. The intention of such activity is reconnaissance for building scripts which will later be used to attack the platform.
The main mechanism used to attack APIs in this context is Man in the Middle (MitM) and although encrypting the traffic is straightforward to implement using TLS, it can relatively easily be decrypted. Certificate pinning is helpful too, but has some risks and challenges relating to both its implementation and management.
For a full discussion about MitM and how best to mitigate it, check out our MitM whitepaper or a recording of our webinar on the topic.
Generally speaking, most of the data and services of interest to bad actors are actually with the backend infrastructure. This is where the data lakes of sensitive data exist and where all of the major business logic resides. As a result, this is usually the target of hackers and the attacks are most commonly executed using scripts or bots.
There are 2 mechanisms being used in these cases:
To consider how best to protect yourself from these attacks, it is important to recognise that the execution path is via a script, or a bot generating automated traffic. Once you realise that, the approach to protection may be simpler than you think; namely that if you can just identify the scripted traffic at the API endpoint, you can block it and only allow traffic from genuine mobile app instances to pass through to backend processing.
Two approaches you may wish to consider to protect mobile platforms are:
These two security approaches are often called Shift Left, referring to the addition of secure code practices into the development phase, and Shield right, referring to the addition of security designed to protect software deployed in production. Check out our two part blog series on this topic; the first article is here.
By now you will be thinking that there are a lot of different options when it comes to securing your mobile platform and you may be a bit confused about where to start. Obviously it isn’t possible to implement all of the options immediately and in fact some of them are probably not necessary. But which ones?
As mentioned above, the approach to follow is to consider the data and services that make up your mobile-centric platform and your use cases that leverage it. Then imagine different scenarios and consider the dangers they imply to your business. For example, what would happen if a user’s live data was extracted from a running app, or an API key was intercepted on an API, or a script impersonated your mobile app to send API requests to your backend? Take each of these and consider how well you could defend yourself against these attacks, and how much exposure you would have if they succeeded. This will help you to build a prioritized list of the protections you need.
Once you have this list then it should start to become clear what security mechanisms you should put in place first. For example, if you conclude that the most serious threat against your business is if your API key got into the hands of hackers and they used it in a script to extract sensitive data from your backend servers, then your highest priority activity is to shield your backend systems from scripts. Before reading this article, you might have thought that your first task should be to add obfuscation and anti-tamper protections in your app to make it more difficult to extract your API key; you should do that too of course, but not until you have first shielded your backend.
In summary, first prevent the attack and second secure against intelligence gathering for the attack. If you would like to discuss your specific use cases and get some guidance on how to approach securing your mobile business, please contact one of our experts here.