Why Your API Keys Are Leaving You Vulnerable to Attack

For years, API security specialists have underscored the importance of safeguarding our APIs. Most companies have implemented an API gateway as a defensive measure against cyberthreats. Nevertheless, many of these APIs rely solely on basic API keys for protection.

Despite the seemingly secure implication of their name, API keys do not offer robust security in practice. APIs that handle sensitive data require a more fortified form of protection, such as tokens rather than API keys.

What Is an API Key?

API keys regulate access and monitor the usage of an API. Developers are usually required to append their unique API key with their requests to interact with an API. The API server then verifies this key to confirm whether the requester has permission to access the resources or execute certain operations.

There are two primary reasons for the widespread use of API keys:

• By standard, every API gateway provides the option to release APIs and manage access using an API key, establishing it as the norm.
• Their ease of use appeals to developers. Incorporating the API key is as straightforward as inserting it in the request path or header.

That Sounds Good to Me. What’s the Issue Here?

Imagine your API isn’t dealing with sensitive information and isn’t critical to your organization’s operations. In such scenarios, using an API key as a security measure might be perfectly fine. Examples where an API key might suffice include APIs providing weather forecasts, store locations or other publicly accessible data.

On the other hand, if your API exposes personally identifiable information (PII) or any data whose compromise could harm you or your organization, you’re vulnerable to unauthorized access, data breaches and the potential abuse of resources.

It’s widely recognized in software engineering that naming things can be incredibly challenging. Much of the misunderstanding may arise from what we infer from the term “key.” In the physical realm, a key secures our homes, vehicles or safety deposit boxes, suggesting robust security. Therefore, it’s understandable to assume that an API key secures your API. Yet, while it offers some level of protection, it’s generally not considered robust by modern standards.

Google has said that API keys are for projects; authentication is for users, whereas authentication is meant for verifying users. In essence, an API key identifies which services a client application can access. The API gateway uses this identifier to impose rate limits, monitor API utilization and occasionally handle billing.

Developers often embed API keys directly into applications. This means every user operates under the same API key, with no individual authentication or authorization checks. Should these keys be exposed or stolen, malicious activities could transpire unbeknownst to the API owner.

API keys are typically issued once and remain valid indefinitely, which is concerning because compromised keys may go unnoticed for an extended period. Due to the simplicity with which API keys can be integrated, developers may become complacent, inadvertently uploading them to public repositories. The existence of tools like git-hound is a testament to the prevalence of such slip-ups.

To Secure or Not to Secure, That Is the Question

In the pursuit of simplicity, we often find that minimal measures, such as passwords, fall short of security. Thus, the advent of two-factor authentication, which, despite adding extra steps to the login process, is widely accepted as a necessary enhancement for protecting accounts. Similarly, the security provided by API keys alone is insufficient; they require the bolstering presence of tokens.

API tokens serve a dual purpose, addressing core security concerns: they verify identity (authentication) and determine access levels (authorization).

HubSpot, recognizing the limitations of API keys, has recently mandated that developers on its platform transition to using access tokens. This move is detailed on its developer site.

Such shifts are becoming commonplace, especially among growing businesses that initially opt for the quickest method to grant API access before acknowledging the necessity of stronger, scalable security measures.

What Is a Token?

An API token is a unique identifier used to authenticate a user or application to the API, serving as a key to access services without transmitting sensitive credentials. It ensures security by encapsulating user permissions, often has an expiration and can be scoped for specific access levels. Typically, a developer is provided with a ClientID and secret that may be used to generate a secure token.

This token-based approach allows for stateless interactions with the API. Since the server does not need to maintain a session state, it can serve many more clients without worrying about the memory overhead of stored sessions, with the added advantage of recovering more gracefully from partial failures.

Tokens can use scope so you can control the access that each integration has to your system. API token scopes are used to limit the access rights of an API token, specifying which resources or actions the token is permitted to access or perform. For example, a cloud storage service may have the following scopes:

• Read: Allows downloading and listing files.
• Write: Allows uploading and modifying file metadata.
• Delete: Allows deletion of files.
• Share: Allows sharing files with other users.

The benefit for the application’s end user is that they can revoke a scope at any time, meaning that they can retract access to, say, their date of birth or gender.

The main advantage of using tokens over API keys is that they’re designed to be regenerated regularly, essentially making it harder to hit a moving target. This means that the API consumer needs to write their code to handle this from the beginning.

Why Doesn’t Everyone Just Use Tokens, Then?

Short answer: It’s more work.

The beauty of an API key is that you can just add it as a query parameter in the URL or header and you’re done:

`GET https://api.example.com/data?apikey=YourAPIKey`

Writing a token-handling service requires a little more effort:

1. Prepare token request: Set up a `POST` request with your `client_id`, `client_secret` and specify the `grant_type as client_credentials`.
2. Send token request: Use a tool like curl to send the request to the service’s token endpoint.
3. Receive bearer token: Extract the `access_token` from the JSON response.
4. Use bearer token: Include the bearer token in the authorization header for API requests.
5. Manage token expiration: Request a new token after the current one expires.

Requiring tokens for API access might dissuade developers, tempting them to opt for a rival’s more straightforward approach. Yet sacrificing robust security for ease of use could result in an API attack. Consider which scenario is less desirable: headlines spotlighting a security breach at a competitor’s API or your team’s API?

Moreover, numerous software development kits (SDKs) can simplify this process for developers. These tools encapsulate the intricacies, allowing developers to integrate and use your API without needing a deep comprehension of the underlying authentication processes.

How Apiable Solved This Problem With Curity

Curity offers a ready-made secure token service and authentication service (for user login) to simplify API developers’ work considerably. Finnish API Portals as a Service startup Apiable uses this to issue secure tokens to clients in three stages:

• Stage 1: Define the supported authorization levels or types at an API program level.

Instances have arisen where each API release to a portal necessitates a prior security assessment. This procedure can be arduous and decelerate the pace of releasing new APIs within a company.

Our recommendation is to allocate time to collaborate with your security personnel to craft a suite of endorsed API authorization protocols specific to your organization. Once these standards are in place, they can be applied consistently across various API products, eliminating the need for repetitive discussions.

👁 Image

• Stage 2: Abstract the complexity away from the API product manager.

Product managers, who frequently come from business backgrounds, may encounter developer queries like, “Which OAuth 2.0 flow is appropriate for this API?” These managers may lack the technical know-how to answer such specific inquiries.

However, with a predefined security framework, API product managers can confidently determine the suitable security level for their offerings, assured by their organization’s endorsement.

This approach aligns with Curity’s API Security Maturity Model and simplifies the decision-making process regarding OAuth 2.0 flows. It enhances the overall comprehension of the security levels of different flows using an easy-to-understand grading scale from 0 to 3, visually depicted by a traffic light color coding from red to green.

👁 Image

👁 Image

• Stage 3: Help the API consumer understand which OAuth flow they should implement.

Developers can find it complex to discern the appropriate OAuth 2.0 flow for their particular scenario, particularly when dealing with multiple API products, each with its own set of supported authorization flows. This complexity often results in a broad “Getting Started” guide encompassing all potential authorization methods.

To streamline this process, once a developer subscribes to an API product, the API portal customizes its display to present only the relevant authorization type for the selected plan and use case, complete with practical examples. This tailored approach allows developers to commence work faster and benefit from an enhanced developer experience.

👁 Image

👁 Image

Note: These credentials were regenerated after this screenshot was taken.

Conclusion

The seemingly straightforward API key is deceptively inadequate for securing APIs that access sensitive data. It may offer a semblance of security, but the static nature of API keys and their broad distribution make them a liability.

On the other hand, tokens provide a dynamic and robust security measure. They ensure that each request is not only authenticated but also authorized, addressing the two fundamental security questions that API keys alone cannot.

The transition from API keys to tokens may initially seem daunting due to the effort required to implement proper token handling. However, the trade-off is a much more secure API ecosystem where sensitive data is better protected against unauthorized access and breaches.

In the digital realm, as in the physical one, the strongest lock is the one that adapts and changes, keeping unauthorized users out. Apiable’s use of Curity’s secure token service demonstrates how organizations can safeguard their APIs without overburdening developers.

By defining supported authorization levels and streamlining security protocols, API product managers can navigate the balance between security and accessibility, ensuring their APIs are both easy to use and safe.

The evolution from API keys to token-based authentication is not just a trend but a necessary step toward a more secure digital infrastructure. This approach represents an investment in the longevity and integrity of an organization’s digital assets, solidifying trust in the technology that underpins our modern world.