Securing API Keys for Robust Mobile API Security

It’s been nearly half a decade since Gartner declared the API economy open, hailing it the enabler that could transform businesses into platforms. Since then, APIs have significantly evolved beyond their rather simple origins as middleware integration tools.

Even today, today, a minority of enterprises still take an integration-first view of APIs. The majority, however, has shifted to an “API as a product” strategy where the focus is on leveraging these key assets for driving efficiencies, accelerating development cycles, adding intelligence to business processes, exploring new growth and revenue opportunities, and future-proofing their business.

However, this growth has not come without its share of challenges. For starters, the value of APIs in driving, growth, revenue, and innovation means an increasing number of non-developers, 53% according to one report, are now involved in the creation and evolution of these strategic assets. Though this has the benefit of further accelerating the adoption of APIs it has also increased the call for greater visibility into the API experience and the need to sift legitimate API traffic from that emanating from bad actors. As APIs proliferate at a frenetic pace within the enterprise, the “connect it and they will come” truism of cyberthreats means that API security may well be the weakest link in a cloud-first approach to enterprise IT.

The use of APIs to service mobile apps, currently the second-ranked use case behind A{Is which service websites, is also growing exponentially driven by the demand for more connected and integrated services on mobile devices. In this channel, APIs are involved in every transaction such that any vulnerability or unauthorized access is a serious threat to profits, reputation, and viability. And APIs servicing mobile applications face a range of critical threats including MitM (Man-in-the-Middle) attacks, data scraping, credential stuffing, app impersonation, as well as DoS and DDoS Attacks.

The API Threat Vector

The widespread use of APIs has opened up a new vector for cyberattacks. API calls have become the preferred vector for DDoS attacks. In 2019, a fifth of all organizations reported that their APIs were daily targets for access violations and denial of service attacks, over and above daily injection attacks and data leakages. Recent research provides further evidence that cyber-attacks against API endpoints have spiked during the ongoing pandemic.

At the same time, the enterprise cost of malicious attacks is also on the rise. For instance, the average total cost of infiltration using stolen or compromised credentials has been estimated at a whopping $4.77 million. Lost business, including revenue and reputation loss, remains the largest cost component of a breach accounting for nearly 40% of the average total cost.

That then is the security conundrum for APIs: implement rigorous security protocols that restrict access and availability of resources and compromise the API experience or streamline access and availability and risk business continuity, revenue, and reputation?

Thankfully, there is a middle path that can augment experience and deter intrusions. Today, API security has already come a long way from the days of anonymous APIs open to any unauthenticated user through the presentation of a simple API key. However, implementation continues to be an issue with the OWASP’s (Open Web Application Security Project’s) API Security Top 10 report highlighting how flawed implementations of authentication mechanisms enable attackers to compromise authentication tokens and hijack user identities.

To API Key or Not?

To paraphrase the OWASP report, any API security system is only as good as its ability to identify remote users and remote client software. And API keys have their tradeoffs, with their inherent simplicity often the source of security concerns.

However the solution cannot be to stop using API keys but instead to ensure that they cannot be easily abused or exploited at scale by automated attack scripts. The focus, therefore, has to be on creating stronger API keys and on the standards of implementation.

For instance, it is not uncommon to find API implementations where the key or the access token is embedded in the URL itself. This is a serious vulnerability because it is very easy for the credential to be logged or cached for future use. Fortunately, there are simple, secure and standardized workarounds to this problem by, for example, putting the key or token in the authorization header or by keeping the API key out of the channel.

Considering in particular the mobile channel, there still remain many cases where API keys need to be stored in mobile apps. There are good and bad ways to do this of course, but the reality is that hackers can still locate them inside the installed application package using disassemblers, decompilers and other reverse engineering tools. Code hardening techniques can help secure mobile app source code by applying layers of obfuscation and encryption to protect against access, analysis and reverse engineering. Obfuscation techniques can be used to transform various aspects of the code, including data, control flow and layout structure, to make them incomprehensible and indecipherable and anti-tamper and anti-debug solutions can even enable a degree of app self-protection whereby it shuts down, crashes or even alerts app developers in the event of any infiltration or tampering.

The State of API Key Security

Earlier this year, a security researcher found an unencrypted Starbucks API key in a publicly available repository that could have been used to access internal systems and manipulate the list of authorized users at the world’s largest coffeehouse chain. In this case, the vulnerability was routed through a bug bounty platform and the issue was resolved without any adverse consequences for Starbucks. 

However, it could have been very different. The fundamental problem is that there is too much focus on 'hiding' API keys in applications so they can't be found, or in preventing keys being inadvertantly left in repos. Instead, the emphasis should be on ensuring that the API keys can't be exploited at scale. This can be achieved by shifting one's mindset to considering the verification of the entity presenting the key. If the transmitting party is required to prove that it is an authentic instance of the expected application then harvested API keys are completely useless to bad actors.

And that brings us back to the primary point that app authentication may be the weakest link in API security. The focus has to be on strengthening the methods through which API keys are used to provide access to backend services and resources, rather than dispensing with them entirely. Providing a so-called second independently validated factor which proves that the key is being served by an authentic remote client is a practical and pragamtic solution. With this approach deployed, we can be much more collectively relaxed when API keys turn up unexpectedly in publicly available software repositories.