Keep real values out of source control
Add secret-bearing filenames to the repository ignore rules before creating them. Commit an .env.example containing variable names, safe placeholders, and comments—not working credentials. Remember that ignore rules do not remove files already committed.
Enable secret scanning in local hooks and continuous integration, but treat detection as a safety net. Obfuscating or base64-encoding a value does not make it safe to commit.
Control local copies
Limit file permissions to the account that needs them. Avoid placing secrets in synchronized desktop folders, support bundles, screenshots, shell history, or shared archives. Development credentials should point to isolated, low-impact systems and expire when practical.
Watch the build boundary
Frontend build variables may be embedded into downloadable JavaScript even when their names sound private. Containers can preserve secrets in image layers if they are copied during a build. Use build-time secret mounts where supported and inspect final artifacts rather than assuming the build tool removed sensitive values.
A variable prefixed for browser exposure is public. Never put a database password or server API secret in client-side configuration.
Prefer runtime identity in production
Production workloads should retrieve secrets through a managed secret store or use workload identity to avoid persistent keys. Policies should bind values to a service and environment, with audit trails and automated rotation.
Respond to accidental commits
Revoke and replace the exposed value first. Removing the file in a later commit does not remove it from history, caches, forks, or existing clones. Rewrite history only as a secondary cleanup step and coordinate it carefully because it disrupts collaborators.
Sources and review basis
This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references: