Unlock an API-first Security Strategy To Tackle Popular Attack Vectors
API keys are still exposed, and this creates a massive attack surface for bad actors to exploit.
Exposed APIs make up 40 percent of the attack surface for web-enabled applications, and it’s expected to more than double by the end of 2021. What do you do? David Stewart, CEO and co-founder, Approov, shares API-first security strategies for API-first initiatives to prevent exploitation.
Mobile app developers know that storing hard-coded API keys in mobile app code is a bad idea. They know this because of many recent high-profile breaches where API keys have been stolen and exploited to steal data. They also know it’s a bad idea because all best-practice recommendations for developers explicitly state not to keep keys and secrets in the code. However, the latest survey results from Osterman Research (“The State of Mobile App Security in 2022” – the full report can be downloaded here) clearly show that API keys are still exposed in this way, creating a massive attack surface for bad actors to exploit.
To make things worse, even if the secrets are not in the source code, they are still in the mobile app because the compiled code is in the public domain, and those keys are still compiled into the release. API keys and other secrets can be reverse-engineered from the code or captured in transit from the mobile app to the backend. Any attacker has complete control of the device and the network it uses, so such attacks are relatively straightforward.
This article seeks to get to the bottom of this issue of exposed API keys and present concrete, actionable advice to developers on making sure API access from mobile apps is always secure and available.
What Did the Osterman Research Find?
Osterman Research surveyed more than 300 security and mobile app development professionals in April 2022 to get a snapshot of the state of mobile app security.
The report finds that three out of four companies now report that mobile apps are core to their business success, with their importance tripling in the last two years. The issue is that this rapid change in the business importance of mobile apps has put pressure on developers to prioritize feature velocity. The consequence, as indicated by other findings in the report, is that security is being somewhat neglected.
The findings in the report concerning API usage clearly demonstrate the tension between providing rich functionality quickly on the one hand and ensuring security on the other. The report shows that the use of APIs has become a key mechanism for mobile apps to deliver a rich customer experience. Respondents reported using dozens of APIs to deliver service; on average, 30 third-party APIs were used per mobile app.
This is fine, except that some of these APIs are being deployed without sufficient controls in place. Specifically, the report shows that half of the mobile apps are still storing API keys as hardcoded secrets and 55% of the respondents who said their keys were exposed actually place a high priority on removing hardcoded secrets.
Let’s actually remind ourselves what can go wrong if bad actors get a hold of your API keys.
See More: How APIs Help Leaders Navigate the Labor Shortage
Why Careless API Key Management Is a Big Problem
API keys are commonly used to secure access to a backend API. Typically, when you use a third-party API, you sign up, and you get allocated a key. This is essentially like a password. It authenticates the app that’s making the call so that the API backend knows which particular app is making the request. This blocks any anonymous traffic and can be used to limit requests. In practical terms, you have to consider the API key to be a secret. If that API key becomes known, then your app can be impersonated, and other parties can make API calls.
Various tools exist that can trawl public source repositories, find those API keys and then abuse them. In the last couple of years, we’ve seen more and more tools that enable you to find API keys that you might have accidentally included in source code, and there are also secret management storage solutions in the market that allow you to separate secrets so that they’re not stored in your source code at all. But, as we mentioned earlier, if secrets are compiled in your app, they are available to bad actors.
So, what can go wrong if API keys are exposed? The risk obviously depends on the capabilities of the particular API whose key has been compromised. It’s possible that having access to an API outside of the app allows some data exfiltration, either directly or indirectly, through vulnerabilities like OWASP excessive data exposure. This is a classic API implementation blunder whereby an API may present more information than it really should but relies on the client to filter what is made available. Once you have the API key, you can access the API directly, perhaps running it on platforms that allow you to see all the data.
Another possibility is that there are API keys associated with crash or installation analytics. You can use that to impersonate the app and post incorrect and misleading data. That undermines the analytics or causes support teams to waste time tracking down seemingly widespread phantom bugs.
Generally, if you are using a 3rd party API, then there is going to be some kind of quota associated with it, so you can’t make so many API calls that the quality of service of others users is degraded. This might be expressed as the total number of APIs calls that may be made per day, hour or minute associated with a particular API key. If that API key is extracted and distributed, bot scripts start making API calls rapidly, then your quota will be quickly exceeded. In effect, this is a Distributed Denial of Service (DDoS) attack. Service is interrupted when calls from the real app are rejected, and it won’t be able to function.
If you use some 3rd party APIs that are on a pay-per-use basis, then the attacker’s motivation might be to be able to make API calls without paying. But you will be paying!
See More: API Implementation: 4 Key Areas To Ensure Good Security Hygiene
How to Protect API Keys and Access to APIs
So, given the risks associated with losing control of API Keys, what are some best practices to keep them safe? Let’s look at the pros and cons of some of the best approaches.
Not using API keys at all
There’s an ongoing debate about whether API keys should be used at all. Some mechanisms allow you to use access tokens instead. One strategy is to have an access token that is associated with a particular app and a particular user, and the access token is obtained when the app is first installed. This can also be associated with user authorization, and there are mechanisms in OAuth2 to allow this. The app performs an authorization step on installation or first use and then obtains an access token that is used to access an API. This ties the access down to an individual user, which is good, but the problem is that it’s actually quite easy for many applications to sign up as a user. You might consider using a client secret in order to protect the initial request for an access token. Unfortunately, now, instead of having an API key to protect, you have a client secret that needs to be protected, with all the same issues.
Code obfuscation
Obfuscation or code hardening provides protection against static reverse engineering. This does protect against bad actors downloading the app from the store and then using tools to statically reverse-engineer keys out of the app. However, this does not protect against runtime or Man-in- the-Middle extraction attacks. Unfortunately, protection is only as good as the weakest link.
Pinning
Pinning is also employed in apps to lock down connections to specific known certificates associated with the backend API servers. This prevents man-in-the-middle extraction from being used easily. However, even if your app uses pinning, then it is still possible to defeat it by using hooking tools running inside the app on rooted or jailbroken devices.
Using a proxy
Another approach is to move the API keys out of the app entirely by communicating with the backend via a proxy rather than directly to the API. The app authenticates itself to that proxy, and then the requests get forwarded on to the actual backend API. Only the proxy itself knows the real third-party API keys and adds them to the forwarded requests. This helps manage the complexity of many APIs and keys but adds some complexity, latency and costs to all the requests. Also, you now have to worry about the resiliency of the proxy because if the proxy goes down, then nothing works. But perhaps the single biggest shortcoming is that you are simply moving the problem rather than really solving it. How do you authenticate the app against the proxy? You’re back to the original problem of needing some kind of secret in the app, and an attacker can extract that secret.
Combining app attestation and key management
The most secure approach is actually to combine two distinct protection mechanisms in a way that they work seamlessly together. The first element is to use an app attestation solution to verify that the application and the client environment has not been tampered with. This type of solution can prevent cloned or modified apps or scripts from ever accessing APIs. The second piece is implementing a cloud-based solution for managing and securely storing API keys. This way, they are no longer present in the built app code at all, and the app is no longer subject to any reverse engineering risk since there are no keys to steal. Combining the two approaches creates a highly effective solution. The app attestation solution reports the status to the cloud key repository, and if the app and/or client environment doesn’t pass its checks, then the keys are never sent back to it. A further significant advantage is that because the secrets themselves are stored in the cloud, they can actually be updated at any point. Previously static secrets that could only be changed by republishing the app now become dynamic. If they need to be changed for some reason or are breached in some other way, they can be changed on the fly.
App-propriate Security
Mobile apps are critical to most businesses today. API use is widespread in mobile apps, but the API keys that are used to validate access are often exposed either in source or compiled code. Such careless API key management exposes businesses to data breaches and service interruptions.
Some approaches can be taken to protect API keys and other secrets from being stolen and exploited. These should be implemented to ensure the uninterrupted and secure operation of the mobile apps essential to today’s business.
How are you ensuring an API-first security strategy? Share with us on Facebook, Twitter, and LinkedIn.
MORE ON APIs:
- APIs — A Bottleneck for SaaS Backup
- How ‘APIfication’ Is Changing the Way Businesses Innovate and Grow
- Why APIs and Microservices Are Vital for Digital Transformation
Image Source: Shutterstock
