Risky app business: hardcoded API keys jeopardize data in the cloud

Warnings of hardcoded API keys in mobile apps persist. But code reviews and software supply chain analysis could turn things around.
8 September 2022

Digital danger: hardcoded keys are a quick workaround that threaten the security of data stored in the cloud. But it doesn’t have to be this way and there are app development tools that can help. Image credit: Shutterstock.

Mobile apps are ubiquitous. Smartphones do a great job of running software that would have previously meant lugging a laptop around, and that’s made mobile apps a popular choice for enterprises. Delving into the software, there are a number of use cases. But a common one is the use of mobile apps as a gateway to accessing information in the cloud – for example, to query a corporate database (or more likely, several databases). For businesses, the productivity gains are clear. And often software designed to be run on smartphones, tablets, or other devices (vehicles are becoming another popular environment for app developers) turns out to be more widely used than its PC equivalent. So far so good, until security issues get in the way.

Search online for “hardcoded credentials on mobile apps” and the problem becomes clear (for the MITRE definition, check out CWE-798). In the early stages of software development it can be tempting to write API keys into the code – for example, to quickly test an app idea, or prototype different solutions. These keys (which are unique and allow servers to identify the application making the request) provide authorization for software on a remote device to read values stored in a database hosted in the cloud. API keys, in themselves, work well and can help servers in other ways too – for example, by allowing them to rate-limit requests; quenching denial of service (DoS) attacks. But keys are keys, and like the real world versions in your pocket or bag, you wouldn’t want everyone to have access to them, while they remain valid.

Persistent problem

Security search engines such as CloudSEK’s BeVigil found (in April 2021) that 0.5% of mobile apps expose AWS API keys. And given how many apps are out there, that’s a lot of keys and a lot of data that is potentially at risk of being breached. It’s important to note that AWS is not the story here. AWS is one of the most popular cloud hosts on the planet, so there’s no surprise to see its keys being widely used. The problem is at the app level and in the software supply chain that goes with it. More recently, Symantec looked into the issue and reported in September 2022 that – in a survey of 1859 publicly available apps (featuring Android and iOS operating systems) – it had found:

  • Over three-quarters (77%) of the apps contained valid AWS access tokens allowing access to private AWS cloud services
  • Close to half (47%) of those apps contained valid AWS tokens that also gave full access to numerous, often millions, of private files via the Amazon Simple Storage Service (Amazon S3)

Worst still, hardcoded credentials is a problem that hasn’t gone away – Symantec’s team raised the same issue three years ago. One reason for the problem’s persistence is that there are numerous ways that these API issues can arise. Kevin Watkins, a security researcher at the firm, notes that some companies outsource the development of their mobile apps, which can lead to vulnerable external software libraries and SDKs being unknowingly introduced. Internally, the use of cross-team libraries can also present issues, when vulnerabilities haven’t been picked up. And shared libraries add to the problem too, where access tokens have been hardcoded.

Security frameworks and tools

If the issue lies in an upstream library, vendors may not even realize that they are using hardcoded credentials, which emphasizes the importance of running security scanning and safe coding tools during software development – Snyk is one example, and there are others too. And touching back on the software supply chain issue raised by Symantec, there are solutions that can be deployed here as well, such as software composition analysis integrations provided by Sonatype.

At this point in the discussion, it’s worth noting that adversaries may have to do a little digging to get their hands on the baked-in secrets. But they will find them. And if those API keys open the doors to a treasure trove of sensitive business data then victims of the breach will be in trouble. There are online guides showing how easy it is to scan code repositories such as GitHub for secrets and credentials. And even simply typing the Linux command ‘strings’ (which lists all of the strings used in a program) could be enough to reveal clumsily hidden secrets. Tools such as MobSF – a security framework for analyzing Android and iOS software – are useful indicators of how good, or bad, the situation is. And Microsoft is very clear in its advice to coders. “When a key is hard-coded, it is easily discovered,” writes the computing giant. “Even with compiled binaries, it is easy for malicious users to extract it.”

Data breaches happen for all kinds of reasons, but shutting the door on the use of hardcoded credentials will certainly help to raise defenses. And there are lots of useful cheat sheets on how to implement secure cryptographic key management. Also, cloud providers such as Google and Amazon offer tools for keeping secrets such as API keys safe. Solutions such as AWS’s secrets manager take much of the heavy lifting out of belt and braces approaches, which includes key rotation – a way of further bolstering security. API hubs can help too. RapidAPI has a useful section explaining how to perform API key rotation or reset an API key that you know to be compromised.