Let's move away from API keys!

  • Thread starter Thread starter Chris_Noring
  • Start date Start date
C

Chris_Noring

API keys managementAPI 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
Click to expand...
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.


Code: 
// 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?
Click to expand...
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?
Click to expand...
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?
Click to expand...
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​





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

Continue reading...
 
Back
Top