Constants and Secrets in Practice

Applications use many values that are not part of their main logic: timeouts, limits, service addresses, passwords, and API keys. These values may all look like configuration, but they should not all be handled the same way.

A constant gives a stable value a meaningful name. A secret is a sensitive value that could cause harm if exposed. They can be used separately or together.

What Is a Constant?

A constant is a value the program should not change while it runs. Naming it makes the code easier to understand and avoids repeating unexplained values:

const DEFAULT_TIMEOUT_MS = 5000;
const MAX_RETRY_ATTEMPTS = 3;

const requestOptions = {
  timeout: DEFAULT_TIMEOUT_MS,
  retries: MAX_RETRY_ATTEMPTS,
};

Constants are usually safe to keep in source code and commit to a repository. Common examples include limits, default settings, file extensions, public URLs, and error codes.

Not every constant belongs in one large global file. Keep it close to the code that owns it unless several parts of the application genuinely share it.

What Is a Secret?

A secret grants access, proves identity, or protects sensitive data. API keys, database passwords, session-signing keys, private certificates, and deployment tokens are common examples.

A simple test is: could someone use this value to access data, impersonate a service, spend money, or bypass a security control? If so, treat it as a secret.

Do not write the value directly in source code:

const apiKey = process.env.PAYMENTS_API_KEY;

if (!apiKey) {
  throw new Error("PAYMENTS_API_KEY is required");
}

The environment variable keeps the value separate from the code, but it does not automatically make the secret safe. The deployment environment must still protect who can view or change it.

How They Work Together

Backend configuration often combines ordinary constants with secrets:

function requireSecret(name: string): string {
  const value = process.env[name];

  if (!value) {
    throw new Error(`${name} is required`);
  }

  return value;
}

export const config = Object.freeze({
  apiUrl: "https://api.example.com",
  timeoutMs: 5000,
  paymentsApiKey: requireSecret("PAYMENTS_API_KEY"),
});

Here, apiUrl and timeoutMs are non-sensitive values that can safely live in code. paymentsApiKey is supplied at runtime and must come from protected storage.

Combining them in one read-only configuration object gives the application a consistent way to access its settings. It does not make every value equally safe to expose: code that needs only the timeout should not receive or log the payment key.

Where Should They Be Stored?

• Put stable, non-sensitive constants in source code or a normal configuration file.
• Put non-sensitive values that differ by deployment in environment variables or deployment configuration.
• Keep local development secrets in an ignored .env file or development secret store.
• Keep production secrets in a managed secret service or protected runtime environment when possible.
• Keep user preferences in user configuration or a database, depending on what owns the data.

Environment variables are a delivery method, not a secret vault. Production secret services can add access control, auditing, rotation, and short-lived credentials.

Keep Secrets Out of Client Applications

Anything sent to a browser, mobile application, or desktop application should be considered discoverable. A build-time environment variable included in frontend JavaScript is visible in the downloaded bundle even if its name contains SECRET.

Keep privileged credentials on a backend you control. The client should authenticate to that backend, which performs only the operations the user is authorized to request.

Some values that look like keys are intentionally public, such as certain analytics identifiers or OAuth client IDs. Follow the provider’s documentation rather than deciding from the name alone.

If a Secret Leaks

Deleting the value from the latest file is not enough because it may remain in repository history, logs, caches, or copied builds.

1. Revoke or rotate the credential immediately.
2. Check where it was exposed and whether it was used.
3. Update the application with the replacement.
4. Remove the leaked value from files and logs.
5. Add secret scanning or another control to prevent a repeat.

Rotation is the security fix. Cleaning repository history may reduce continued exposure, but it cannot make the old credential safe again.

The Main Idea

Constants describe stable program behavior and are usually safe to share. Secrets provide sensitive authority and must be protected, limited, and replaceable.

Use them together when building configuration, but keep the boundary clear: constants explain how the program behaves; secrets grant access to something protected.