Separate environment configs for dev/staging/prod

Using the same environment configuration across development, staging, and production means a developer mistake in a test environment can hit production data, a staging webhook fires against live Stripe, or a misconfigured query runs against the production database. CWE-1188 (Use of Hardcoded Default Values) and OWASP A05 both flag shared configurations as a misconfiguration risk. NIST CM-6 requires controlled configuration management — shared .env files with no environment separation make that impossible to enforce. Beyond security, shared configs make incident response harder: you cannot revoke a staging credential without also revoking the production one.

Create distinct configuration files for each environment and load them based on NODE_ENV. Each file must use environment-specific credentials, endpoints, and API keys — never the same values.

.env.development   # local dev: localhost DB, Stripe test keys, sandbox API endpoints
.env.staging       # staging server: staging DB, Stripe test keys, staging endpoints
.env.production    # production server: production DB, Stripe live keys, production endpoints

// At server startup
import dotenv from 'dotenv'
dotenv.config({ path: `.env.${process.env.NODE_ENV ?? 'development'}` })

All three files go in .gitignore. Maintain a .env.example with placeholder values for each variable so new developers know what to fill in.