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.
Critical because test credentials silently disable payment processing, email delivery, and third-party authentication in production — users take real actions that produce no real outcome.
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: pre-launch.infrastructure.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
.env.local.NEXTAUTH_URL, NEXT_PUBLIC_APP_URL, or equivalent has your real production domain, not localhost.