highCWE-547A05:2021

Dev Environment Variables in Production

Using development credentials (test API keys, local database URLs, sandbox payment keys) in production puts real users at risk.

How It Works

Development environment variables often point to test services, less secure configs, or services with relaxed rate limits. Using Stripe test keys in production means no real payments are processed. Using a local or staging database URL in production routes user data to the wrong database. Both expose your application to data loss or security compromise.

Vulnerable Code
// BAD: test/dev credentials used in production
STRIPE_SECRET_KEY=sk_test_4eC39HqLyjWDarjtT1zdp7dc  # test key — charges aren't real!
DATABASE_URL=postgresql://localhost:5432/myapp_dev  # local DB — wrong environment
NEXT_PUBLIC_API_URL=http://localhost:3000  # localhost — nothing works in prod
Secure Code
// GOOD: production-specific credentials in production environment
STRIPE_SECRET_KEY=sk_live_...  # live key — real charges
DATABASE_URL=postgresql://prod-host:5432/myapp_prod  # production DB
NEXT_PUBLIC_API_URL=https://myapp.com  # production URL

Real-World Example

Several startups have launched to production with Stripe test keys configured, resulting in users completing the checkout flow but no actual charges being processed — leading to revenue loss and user confusion until the mistake was caught.

How to Prevent It

  • Use environment-specific variable names and document which values are required for each environment
  • Add a startup validation script that checks known production-only values (e.g., Stripe live key prefix 'sk_live_')
  • Use separate .env.production and .env.development files, never sharing values between them
  • Audit all environment variables before every production deployment

Affected Technologies

Node.js

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities