In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.
If you are looking to protect your own API backend, not a Third Party one, there are many articles on this site on this topic. If interested you can take a look at the blog posts tagged with API, or if you prefer you can read this series on Mobile API Security to get you started on the right track.
An alternative to the use of a Reverse Proxy to secure the secrets used to call Third Party API's, without the need to use a backend, it's to use instead a mechanism to securely delivered secrets dynamically to your Mobile App just-in-time of them being required to make the API Request, thus if that is what you are looking for you may want to read instead Hands-on Mobile App and API Security - Runtime Secrets Protection.
Let’s dive into the details of what, when and why Third Party APIs are better protected when accessed from within a Reverse Proxy.
Any time you need to access a service, free or paid, which is provided by an entity outside your organization, you are using a Third Party API. Common examples are payment providers, social networks, weather services, etc.Sometimes even APIs from inside your own organization can be considered Third Party APIs, if they come from another part of the company and you have no control over them. In such situations, you might well want to place those APIs in the same categories as the Third Party APIs you use from a security perspective.
Generally, all Third Party APIs require a secret in the form of an API key, Access Token or some other mechanism for a remote client to identify itself to the backend server with which it wishes to communicate. Herein lies the crux of the problem of accessing it from within your mobile app, because you will need to ship the required secret(s) within the code (the coloured keys in the above graphic).
Now you may say that you have obfuscated the secret within your code, hidden it in the native C code, assembled it dynamically at runtime, or even encrypted it. However, in the end all an attacker needs to do in order to extract this secret is to reverse engineer the binary with static binary analysis, or hook an instrumentation framework like Frida into the function at runtime which will return the secret. Alternatively an attacker can inspect the traffic between the mobile app and the Third Party API it is connecting to by executing a MitM (man-in-the-middle).
With the secret in their possession, the attacker can cause a lot of damage to an organization. The damage can be monetary, reputational and/or regulatory. Financially, the attacker can use the extracted secret to access your cloud provider and your pay-per-call Third Party APIs in your name, thus causing you additional costs. Further, you may be financially hurt by the exfiltration of data which may be sold to your competitors or used to commit fraud. Reputationally you can be impacted when the attacker uses the extracted secret to post on your behalf on social networks, creating a public relations nightmare. Another reputational damage can occur when an attacker uses the Third Party API and violates its terms & conditions (for example where frequent usage of the API triggers rate limits) such that you get blocked from using the service, creating pain for your end users. Last but not least are regulatory troubles caused when the extracted secret is the only mechanism of protecting access to confidential information from your Third Party API. If the attacker can retrieve confidential information such as Personal Identifiable Information (PII), regulatory fines connected to violations of GDPR in Europe, or the new CCPA Data Privacy Law in the California, may be enforced against your business.
So the take home message is that any secret you ship in your code must be considered public from the moment you release your app or push the code to a public repository. By now it should be clear that the best approach is to completely avoid accessing Third Party APIs from within a mobile app; instead you should always delegate this access to a backend you can trust and control, such as a Reverse Proxy.
A Reverse Proxy is a type of server, serverless or not, that sits between a client and one or more services, from where the client needs to retrieve or deliver some data to, independent of content type. The Reverse Proxy acts as a mediator between two parts that shouldn’t, and/or don’t need to, be in direct contact. Thus the client doesn’t need to know the address of the service it is trying to contact, nor does it need to expose the credentials required to identify/authorize itself to the service. Instead, this is all delegated to the Reverse Proxy which secures and keeps private both the addresses and credentials related to each Third Party API or service.
Access to Third Party services is normally protected by some kind of secret, such as an API key, which is used by the backend server to confirm the identity of the remote client who requests to use the service. Consequently you want to keep these secrets private and have direct control of their usage, but since you don’t have access to the Third Party API backend, you cannot implement your own mechanisms to defend against API Keys abuse. This is precisely where a Reverse Proxy can be of great help because you will use it to access the Third Party APIs directly, therefore you will have a server that you are in control of and where you can apply as many layers of defense as you want, while keeping the API access secrets out of reach of the public domain, just like in a vault.
Another use case for a Reverse Proxy is when you have a backend within your own organization of which you have no control. In such cases it is often easier to implement a Reverse Proxy rather than fighting with the internal organisation to get security controls implemented on the API.
By now you may be wondering about how you will secure the secret to access the Reverse Proxy in the first place, namely the purple key inside the mobile devices in the graphic above, from being extracted by the bad guy wearing the orange hat? Keep reading - we are coming to that.
As was stated earlier, a golden rule that we always recommend is to not access third party APIs directly from your mobile app because this requires you to ship the secrets required to access the APIs inside the mobile app itself. Instead we strongly suggest that this be done by a Reverse Proxy.
So far we have discussed the use case of a single mobile app accessing several Third Party APIs. However the proposition for using a Reverse Proxy becomes even more compelling when you have several mobile apps accessing the same Third Party service because now you have created a single uniform way to deal with securing the access.
A great reason for using a Reverse Proxy is that allows the different mobile apps in your organization to communicate with Third Party services through a single security gateway. In this way, the real Third Party APIs backend, URLs and IP addresses are not exposed, and all security checks can be carried out in one place.
Moreover, any secrets necessary to access any Third Party APIs will be kept out of the public domain, thus out of reach of attackers. It is of course theoretically possible for an attacker to gain access to the server or cloud service running your Reverse Proxy, but this is a significantly more difficult task compared to reverse engineering or performing a MitM attack against a mobile app to extract the secrets directly.
Caching the result of token or key checking is always a good mechanism to avoid repetitive work, since it is known to always yield the same result. Thus caching will save on resource consumption in the original backend, while at the same time increasing response speed of an application to the end user.
If the Reverse Proxy is used across several mobile apps to unify the access to Third Party APIs and/or backends that you are not in control of, it will require fewer developers/DevOps resources to maintain and secure it, thus freeing those resources up to focus on other tasks.
So your developers can spend more time on business logic while your DevOps people can spend more time in maintaining and securing the rest of your infrastructure.
The Reverse Proxy is the natural choice to manage access to Third Party APIs, and becomes even more suitable when you have several mobile apps consuming the same Third Party APIs.
A recurring theme in this article was the advice not to access Third Party APIs directly from a mobile app. As we have discussed, once your mobile app is released any secret in it becomes public, thus up for grabs by attackers to use on your behalf. If you are not careful you will be the one paying the bill or finding that your free tier resources have been exhausted by someone else.
In the next blog post we'll introduce an off the shelf severless Reverse Proxy in the AWS API Gateway that it's specifically designed to remove the need for any secrets to be stored in a mobile app. Another alternative is to not use a Reverse Proxy and just use the Runtime Secrets Protection to have secrets dynamically delivered only to valid instances of your Mobile App, thus preventing them being reverse engineered with static binary analysis or extracted with runtime attacks.
Paulo Renato is known more often than not as paranoid about security. He strongly believes that all software should be secure by default. He thinks security should be always opt-out instead of opt-in and be treated as a first class citizen in the software development cycle, instead of an after thought when the product is about to be finished or released.
