Environment Variables Security Checklist: 23-Item Guide

TL;DR

Add every .env file to .gitignore, and never put a secret behind a NEXT_PUBLIC_ or VITE_ prefix. Production values belong in your hosting platform's settings, not in a file you deploy. Keep development and production on different keys. If a secret was ever committed, it's compromised: rotate it. 7 critical items must be fixed before launch, 10 important items within the first week, and 6 recommended items when you can.

Env vars look simple. They're also one of the most common sources of security incidents. One wrong prefix and your secret key ships to the browser, sitting in a bundle anyone can download. Miss a single gitignore entry and your credentials are on GitHub for the world to see. This checklist catches the mistakes that trip up experienced developers too.

Quick Checklist (5 Critical Items)

.env in .gitignoreBase .env file should not be committed

Secrets don't have public prefixesNEXT_PUBLIC_, VITE_, REACT_APP_ expose to browser

Production secrets set in hosting platformVercel, Railway, Render environment settings

No secrets in git historyIf committed, consider it compromised and rotate

API keys don't have public prefixesDatabase URLs, auth secrets, API keys should be server-only

.gitignore Configuration 4

.env in .gitignoreBase .env file should not be committed. How to secure .env files

.env.local in .gitignoreLocal environment overrides should not be committed. How to secure .env files

.env.production in .gitignoreProduction secrets should never be in version control. How to secure .env files

.env.example committed (without real values)Template file with placeholder values for documentation. How to create .env.example

Client vs Server Variables 3

Secrets don't have public prefixesNEXT_PUBLIC_, VITE_, REACT_APP_ expose to browser. How to separate client/server keys

API keys don't have public prefixesDatabase URLs, auth secrets, API keys should be server-only. How to secure API keys

Only public config uses public prefixesAnalytics IDs, public API URLs, feature flags are okay. How to categorize config

Production Configuration 4

Production secrets set in hosting platformVercel, Railway, Render environment settings. How to configure env variables

No .env files deployed to productionUse platform's secret management, not files. How to deploy env variables

Different values for dev/staging/productionDon't use production keys in development. How to manage API keys

All required variables documented.env.example lists all needed variables. How to document env variables

Secret Hygiene 4

::checklist-item{label="No secrets in code comments" description="Don't leave "old" API keys commented out. How to review code for secrets"} ::

No secrets in git historyIf committed, consider it compromised and rotate. How to rotate secrets

Secrets not loggedDon't log environment variables in your app. How to secure logging

Secrets not in error messagesError handling shouldn't expose connection strings. How to handle errors securely

Framework-Specific Checks 4

Next.js: NEXT_PUBLIC_ only for public dataServer components can access non-prefixed vars. How to use Next.js env variables

Vite: VITE_ only for public dataUse server-side endpoints for secrets. How to use Vite env variables

Create React App: REACT_APP_ only for publicCRA apps need a backend for secrets. How to use CRA env variables

Node.js: dotenv only in developmentProduction should use real env vars, not files. How to use Node.js env variables

What To Do If Secrets Are Leaked 4

Immediately rotate the secretGenerate new key/password/token in the service dashboard. How to rotate secrets

Update production with new secretDeploy with the new value before revoking old one. How to deploy env variables

Check for unauthorized usageReview logs for suspicious activity during exposure. How to audit API usage

Don't try to remove from git historyIt's still in forks and clones. Just rotate the secret. How to respond to secret leaks

How to Use This Checklist

Work through each section in order. The mistake that shows up most often is a public prefix on something that should have been server-only, which quietly puts the value in your browser bundle where anyone can read it.

What happens if I accidentally commit a secret?

Consider it compromised, right away. Rotate it: generate a new one in the service's dashboard, update your production environment with the new secret, then revoke the old one. Don't waste time trying to scrub it from git history.

How do I know if a variable is exposed to the browser?

Check your framework's documentation, though the pattern is the same everywhere. A prefix marks a variable as public. Next.js uses NEXT_PUBLIC_, Vite uses VITE_, and Create React App uses REACT_APP_. Anything carrying one of those prefixes gets bundled into your client-side code.

Should I use a secrets manager?

For most small to medium projects, your hosting platform's environment variable management is sufficient. Consider dedicated secrets managers like HashiCorp Vault or AWS Secrets Manager when you need advanced features like automatic rotation, audit logging, or cross-service secret sharing.