Environment Variable Security
Practices for securely managing application configuration and secrets through environment variables without exposing them to unauthorized access.
Description
Environment variables are a standard mechanism for configuring application behavior across different deployment environments without modifying code. They are commonly used to store database connection strings, API keys, feature flags, and service URLs. While environment variables are preferable to hardcoded values, they are not inherently secure and require careful handling to prevent exposure.
The security risks of environment variables include accidental logging (many logging frameworks dump the full environment), exposure through process listing (on shared systems), leakage via error pages or debug endpoints, inclusion in container images, and transmission to child processes. In serverless and containerized environments, environment variables may be visible through platform APIs to anyone with deployment access, blurring the line between configuration and secrets.
Best practices include separating true secrets from non-sensitive configuration, never logging environment variables, using .env files only in local development with strict .gitignore rules, validating required variables at startup to fail fast, and using typed configuration schemas. For production environments, prefer injecting secrets from a dedicated secrets manager rather than setting them as plain environment variables. Libraries like envalid or zod can validate and type-check environment variables at application startup.
Prompt Snippet
Validate all environment variables at application startup using a typed schema (envalid or Zod's z.object with z.string().min(1)) to fail fast on missing configuration. Separate sensitive secrets from non-sensitive config by prefixing (e.g., SECRET_DB_PASSWORD vs CONFIG_LOG_LEVEL). Ensure .env files are in .gitignore and use .env.example with placeholder values for documentation. Never log process.env or include it in error responses. In production, source secrets from a secrets manager (AWS SSM Parameter Store, Vault) rather than raw environment variables, and use distinct credentials per environment (dev/staging/prod).
Tags
Related Terms
Secrets Management
The practice of securely storing, accessing, rotating, and auditing sensitive credentials like API keys, tokens, and passwords.
Encryption at Rest
The practice of encrypting stored data so it remains unreadable without the appropriate decryption key, even if the storage medium is compromised.
Principle of Least Privilege
A security principle requiring that every user, process, and system component be granted only the minimum permissions necessary to perform its function.