Because it is easy to extract strings from an application source code or binary, secrets should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

Secrets should be stored outside of the source code in a configuration file or a management service for secrets.

This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.

Ask Yourself Whether

The secret allows access to a sensitive component like a database, a file storage, an API, or a service.
The secret is used in a production environment.
Application re-distribution is required before updating the secret.

There would be a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Store the secret in a configuration file that is not pushed to the code repository.
Use your cloud provider’s service for managing secrets.
If a secret has been disclosed through the source code: revoke it and create a new one.

Sensitive Code Example

const API_KEY = "1234567890abcdef"  // Hard-coded secret (bad practice)

const response = await fetch("https://api.my-service/v1/users", {
  headers: {
    Authorization: `Bearer ${API_KEY}`,
  },
});

Compliant Solution

const API_KEY = process.env.API_KEY;

const response = await fetch("https://api.my-service/v1/users", {
  headers: {
    Authorization: `Bearer ${API_KEY}`,
  },
});

Ask Yourself Whether

Recommended Secure Coding Practices

Sensitive Code Example

Compliant Solution

See