Starbucks Signboard

Leaked, But No Damage Done: Starbucks API Key in Public Repository

Closed White and Green Starbucks Disposable Cup
Source: Pexels

Organizations’ web application programming interfaces (APIs) are both a major asset and a huge potential liability. On the one hand, the level of access and efficiency provided by an API can create significant value for customers. On the other hand, the easy access that an API provides to sensitive data and potentially valuable functionality can be a huge help to cybercriminals.

APIs are vulnerable to a wide variety of potential threats from injection attacks to exploitation of improper user authentication. However, a commonly overlooked threat to web API security is leakage of API keys on sites like Github.

Starbucks API Key Leaked on Github

Github is designed to enable collaboration of teams on a software project by managing version control for code repositories. A team can set up a “master” repo on Github, clone that repo to local machines to perform development, and then push their edits to the master repo. Github makes it easy to merge edits from multiple users and track the development of code over time.

However, Github also makes it easy for developers to accidentally upload data to a public repo. Recently, Starbucks leaked an API key on Github. The issue was discovered on October 17 and remediated on the 21st, and the company paid the discoverer a significant bug bounty a few weeks later. In this case, the researcher who discovered Starbucks’ error received the maximum possible payout from the organization’s bug bounty program. The reason for this is the significance of the API key that was found leaked on Github.

The API in question was for a JumpCloud API that belonged to Starbucks. JumpCloud is an alternative to Azure Active Directory. JumpCloud provides single sign-on (SSO) access control for web apps, Lightweight Directory Access Protocol (LDAP), and user management in cloud environments. The power of this API key meant that it could have devastating impacts for Starbucks if found and misused by a cybercriminal. With the key, an attacker could list all systems and users in the organization’s AWS deployment, take control of the Starbucks AWS account, run commands on systems, and manage users in the cloud deployment.

The potential consequences of this single API key leak make it clear why Starbucks decided to pay their full bounty amount for the report. However, it also demonstrates the potential dangers of API key leaks.

The Problem of Public Repos for API Security

While the Starbucks leaked API key is unusually significant, the organization is far from the only one that has accidentally leaked API keys. North Carolina State University (NCSU) performed a six-month study to determine the extent of accidental leakage of sensitive data on Github.

During their research, NCSU scanned over 2.5 billion files from 3.4 million Github repos looking for sensitive data, including API and cryptographic keys. During this scanning effort, they found 201,642 unique keys scattered over 100,000 different repositories. The long duration of their study (six months), also enabled them to observe how the owners of this leaked data reacted to the issue. Within 16 days of a leak, only 19% of the leaked keys were removed, meaning that 81% of developers never realized their error.

The reason for these leaks is that these users are inappropriately using Github’s import functionality. Embedding API keys in scripts is an understandable mistake as these scripts may require access to services via their API. However, these API keys should not be included when the files in a local copy of a repository are pushed to a public repo on Github.

Github includes functionality for ignoring certain files and folders when performing an upload to a public repository. When developing programs that require access to API keys, these keys should be stored in a special directory with that directory marked to be ignored during uploads. Embedding API keys directly in a script file makes it far too easy for the API key to be accidentally uploaded and leaked.

In the event that an organization accidentally pushes an API key to a Github repository, Github has a service that automatically scans for API and cryptographic keys within uploaded files. However, as demonstrated by the Starbucks incident, this service is not perfect, and a single missed key could have significant negative consequences for an organization’s security.

Securing APIs Despite Key Leakage

This accidental API key leakage by Starbucks demonstrates the potential impact of accidentally pushing an API key to a public Github repository. In this case, the API key in question could have allowed an attacker to take control of the organization’s AWS account.

Implementing best practices for managing API keys is an important component of API security. This includes ensuring that API keys are not embedded in script files and scanning files before they are pushed to public repositories.

However, despite these precautions, it is possible that API keys will still be leaked on Github or similar sites. Organizations must have solutions in place to deal with this eventuality. Deploying behavioral analytics on web APIs can help to detect use of stolen or leaked API keys by malicious actors. The typical behavior of a legitimate user will likely differ from that of a cybercriminal exploiting that user’s access to their account via a breached key. Monitoring for and responding to these behavioral anomalies can mean the difference between an API key leakage resulting in a data breach or a non-event.

Featured Image Source: Pexels

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top