Fix guide · medium · exposed_env_development
.env.development deployed to production
A /.env.development file is reachable in production. Usually contains throwaway dev creds — but reveals which services your app depends on and which env-var names are expected.
Why it matters
.env.development is almost always less sensitive than .env.production — by convention it holds local-dev credentials that work against developer-side databases and sandbox API keys. The risk is reduced but real:
- Reconnaissance value. The variable NAMES reveal your dependency map. An attacker who sees
OPENAI_API_KEY,STRIPE_SECRET_KEY,SUPABASE_URL, andPOSTMARK_API_TOKENknows exactly which integrations to probe. - Feature flag disclosure.
ENABLE_BETA_FEATURE_X=truereveals roadmap. - Sometimes-leak real creds. Developers occasionally paste a production API key into
.env.developmentfor "just testing in prod for a sec" and forget to remove it.
Severity is medium because the leak is more often reconnaissance than direct credential exposure.
How to fix it
Same shape as /fix/exposed_env_staging:
- Remove the file from the production deploy.
- Audit each variable for production reuse and rotate.
- Be explicit in your build script about which env file is included.
- Block all
.env.*paths at the edge.
Did vibecheck flag this on your app?
If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.
Run another inspection