Environment variables are production values

Shipping a production app with test or sandbox credentials is among the most common vibe-coded project failures: Stripe charges go nowhere (pk_test_ keys process no real money), transactional emails vanish into sandbox inboxes, and OAuth flows silently reject real user tokens. CWE-798 and OWASP A05 both flag hardcoded or misconfigured credentials as a critical vulnerability class. Beyond service failures, a localhost DATABASE_URL in production means every API call hits a dead connection — the app appears live but is entirely non-functional.

Audit every service integration before going live. Check the hosting platform's environment variable configuration, not just your local .env.local.

# List all environment variables configured for production (Vercel)
vercel env ls production

Confirm: Stripe uses pk_live_/sk_live_ keys, not pk_test_. Email providers use production SMTP or API credentials. NEXTAUTH_URL or NEXT_PUBLIC_APP_URL points to your real domain, not localhost. OAuth app client IDs belong to a production app with your real domain in the authorized redirect URIs. After switching to production credentials, trigger a test payment, user registration, and transactional email to verify end-to-end.

• ID: env-vars-production

• Severity: critical

• What to look for: Count all environment variable references in the codebase. Enumerate which are required for production vs. development-only. Examine .env.example for the expected environment variable names. Look for any .env files in the project (other than .env.example). Check framework config and initialization code for environment-specific branching (e.g., if (process.env.NODE_ENV === 'development')). Look for common staging/test value indicators: API keys with _test_, _sandbox_, _dev_ prefixes in variable names. Check Stripe configuration for pk_test_ vs pk_live_ key patterns in how the env var is named or documented. Check for any hardcoded localhost URLs in non-dev config paths. Before evaluating, extract and quote the first 5 environment variable names referenced in the codebase (names only, not values).

• Pass criteria: Environment variable names follow production naming conventions, no evidence of test/sandbox service keys being used in production (e.g., Stripe test keys should not be in production env), and no localhost URLs in production-facing configuration. 100% of required production environment variables must be configured in the hosting platform.

• Fail criteria: Evidence of test/sandbox API keys configured for a production deployment context, or localhost/127.0.0.1 URLs in production configuration files, or environment variable documentation shows test values set as defaults.

• Skip (N/A) when: Never — environment variable hygiene applies to all projects.

• Do NOT pass when: Environment variables are set but contain development/test values (e.g., DATABASE_URL pointing to localhost, API keys with "test" or "dev" in the name).

• Cross-reference: For debug mode that depends on environment, see debug-mode-disabled.

• Detail on fail: "Evidence of test/sandbox configuration for production deployment: Stripe test key pattern referenced in production env setup, or localhost URL in production config"

• Remediation: Using test/sandbox credentials in production is a frequent vibe-coded project failure. Payments don't process, emails don't deliver, and third-party integrations silently fail:

  # Verify all required env vars are set in Vercel
  vercel env ls production
  

  1. Audit every service integration: Stripe (pk_live_ not pk_test_), email providers (production SMTP credentials), OAuth apps (production client IDs), CDN/storage buckets (production credentials).
  2. Ensure your hosting platform's environment variable configuration (Vercel dashboard, Netlify environment variables) contains production values — not values from your local .env.local.
  3. Check that NEXTAUTH_URL, NEXT_PUBLIC_APP_URL, or equivalent has your real production domain, not localhost.
  4. After deploying with production credentials, trigger a test payment, registration, and email to confirm end-to-end functionality.