Skip to main content

Sensitive information in source code - API Key

Need

Secure storage of sensitive information such as API keys

Context

  • Usage of TypeScript for statically typed JavaScript development
  • Usage of Express for building web applications and APIs

Description

Non compliant code

import express from 'express';

const app = express();

const apiKey = 'my-api-key'; // Vulnerable code: storing API key in plain text

app.get('/api/data', (req, res) => {
// Your code here
});

app.listen(3000, () => {
console.log('Server is running on port 3000');
});

In the given code, there is a vulnerability where the API key is stored in plain text in the source code. This means that anyone with access to the source code can easily obtain the API key.

Storing sensitive information, such as API keys, in plain text in the source code is a security risk. If an attacker gains access to the source code, they can easily extract the API key and potentially use it for malicious purposes.

This vulnerability can have several impacts. First, an attacker can use the API key to generate an elaborate brute-force attack on the application's encrypted messages. This can lead to unauthorized access to sensitive data or compromise the security of the application.

Additionally, the API key can be used to easily access information within a company, website, or API, leading to sensitive data exposure. This can result in data breaches, financial loss, or damage to the reputation of the affected organization.

To mitigate this vulnerability, it is recommended to load encryption keys from more secure sources. This can include using a key vault service, where the encryption key is securely stored and accessed through an API. Another option is to store the encryption key in a configuration file that is properly encrypted. Lastly, using administrative environment variables can also provide a more secure way to store and access sensitive information like API keys.

Steps

  • Remove the API key from the source code.
  • Store the API key in a secure location such as a key vault service.
  • Retrieve the API key from the secure location at runtime.
  • Update the code to use the retrieved API key when needed.

Compliant code

import express from 'express';

const app = express();

// Retrieve the API key from a secure location
const apiKey = retrieveApiKey();

app.get('/api/data', (req, res) => {
// Your code here
});

app.listen(3000, () => {
console.log('Server is running on port 3000');
});

function retrieveApiKey() {
// Code to retrieve the API key from a secure location
// For example, using a key vault service or a configuration file
// Make sure to properly encrypt the API key
// Return the retrieved API key
}

The fixed code addresses the vulnerability of storing sensitive information, such as an API key, in plain text within the source code.

In the fixed code, the API key is not hardcoded or stored directly in the source code. Instead, a function called retrieveApiKey() is used to retrieve the API key from a secure location.

The retrieveApiKey() function is not implemented in the code snippet, but it is assumed that it retrieves the API key from a secure source, such as a key vault service or a properly encrypted configuration file. This ensures that the API key is not exposed in plain text within the source code.

The retrieveApiKey() function should be implemented separately and should handle the retrieval of the API key securely. It should use appropriate encryption techniques to protect the confidentiality of the key. Once the key is retrieved, it is stored in the apiKey variable.

The app.get('/api/data') route handler is not modified in the fixed code snippet. However, it is important to note that any sensitive operations or data access within this route handler should also be handled securely to prevent further vulnerabilities.

By implementing the retrieveApiKey() function and retrieving the API key from a secure location, the fixed code ensures that the API key is not exposed in plain text within the source code, mitigating the risk of unauthorized access to sensitive information.

References