Let's move away from API keys!

API keys management

This is the first part in a series of security practices on Azure

You want enterprise-grade security but don’t know where to start. You’ve heard terms like Entra ID and Managed identity or maybe even Service principal but where do you go from here? Let’s start here with this series on security.

35% of all exposed API keys are still active – 35% of exposed API keys still active, posing major security risks – Help Net Security

That’s a pretty scary statement, that means services are being misused most likely, data is actively being stolen and so on.

Let’s try to understand why the concept of API keys is a problematic one and how we can move away from it.

What’s the problem with using API keys?

API keys feel great to use right, you get your key, you talk to the API, you’re productive, happy days, right?

From a developer standpoint it’s surely a great experience, it’s fast, it just works.

// Define the API endpoint and the API key
const apiEndpoint = ‘https://api.example.com/data’;
const apiKey = ‘your_api_key_here’;

// Function to call the API
async function fetchData() {
try {
const response = await fetch(apiEndpoint, {
method: ‘GET’,
headers: {
‘Content-Type’: ‘application/json’,
‘Authorization’: `Bearer ${apiKey}`
}
});

if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}

const data = await response.json();
console.log(data);
} catch (error) {
console.error(‘Error fetching data:’, error);
}
}

// Call the function to fetch data
fetchData();

There is a security downside though, or several:

Using API keys can pose several security risks if not managed properly. Here are some key issues:

Exposure

API keys can be accidentally exposed in public repositories, such as GitHub, leading to unauthorized access. This is a common issue when keys are hardcoded into source code.

But can’t I just rotate my API keys often?

It decreases the risk if you rotate keys, but there are other problems. With keys like this you are often given full access to the API, or more access than you intended.

Static nature:

API keys are often static, meaning they don’t change unless manually updated. This makes them vulnerable to misuse if they fall into the wrong hands.

I rotated the keys as soon as we learned they were exposed, that’s surely enough or?

There are scripts always running, scanning large repositories, your keys could have been picked up in minutes, do you know for how long you’ve been exposed for? In that time, think how much damage a bad actor can have done.

Lack of Granular Control

API keys typically provide broad access to the API, lacking the fine-grained permissions that more secure methods like OAuth offer.

I can just create different types of API keys for different parts of the API, no?

Yes, you can do that, but there are solutions in place for easily creating users, groups, permission levels, a common saying with security, unless you are a security company, “don’t roll your own”.

Insecure Storage

Storing API keys in insecure locations, such as within the app’s code or in unencrypted files, can lead to easy extraction by malicious actors².

Do you know where your API keys always live? bonus points if you have in an Azure Key Vault

Secret Sprawl

API keys can proliferate across various apps and services, increasing the risk of exposure and making it difficult to manage and secure them effectively¹.

Yes, API keys can be reused in many places, and it might be cumbersome to replace API keys fast enough depending on how you set this up.

Which leads to:

Ok, so what can all this lead to, why is this so important?

From a security standpoint, these issues can lead to:

Data Breaches: Unauthorized access to sensitive data if API keys are compromised.
Privilege Escalation: Attackers can use exposed keys to gain higher levels of access within a system.
Service Disruption: Malicious use of API keys can lead to denial-of-service attacks or other disruptions.

How to fix it?

To mitigate these risks, it’s recommended to use dynamic credentials like

OAuth is an open standard for access delegation. OAuth allows users to authorize third-party applications to access their information on another service without sharing their credentials. Instead of sharing passwords, OAuth uses access tokens. These tokens are issued by an authorization server and contain specific permissions about what data the third-party app can access. OAuth also defines scopes, which specify the level of access granted. In conclusion, by not sharing passwords, OAuth reduces the risk of credential theft. Even if a token is compromised, it has limited scope and can be easily revoked
Store secrets securely, keys, and secrets in general, don’t belong in source code or in files that are checked into version control. If you can, store them in a service like for example Azure Key Vault
Regularly rotate your keys. Ensure your API keys are replaced regularly with new keys. Make sure you know how long ago you replaced a key, make sure services relying on this API key are managed.
Apply a cloud vendor’s recommendation on best services for protecting your secrets and cloud resources.

References

35% of exposed API keys still active, posing major security risks. https://www.helpnetsecurity.com/2024/08/13/api-keys-secrets/.
Is the API-key enough? API security issues and their fix. https://api-university.com/blog/is-the-api-key-enough-common-api-security-issues-and-how-to-fix-them/.
Keep API Keys Safe, Because The Repercussions Are Huge. https://nordicapis.com/keep-api-keys-safe-because-the-repercussions-are-huge/.
API Keys ≠ Security: Why API Keys Are Not Enough – Nordic APIs. https://nordicapis.com/why-api-keys-are-not-enough/.

In our next part, we’ll talk about Managed identities in Azure.

Microsoft Tech Community – Latest Blogs –Read More

Cart

Cart

Let’s move away from API keys!