Common secrets management mistakes in software development

Few secret leaks involve sophisticated attacks. Most come from ordinary habits that are easy to fall into and easy to fix. These are the ones that show up again and again.

Committing secrets to Git

A key committed once lives in history, forks, and clones even after you delete the file. Prevent it with a .gitignore entry for .env, a pre-commit scanner, and platform push protection. Details in how to keep secrets out of Git repositories.

Using the same credentials everywhere

One database password across development, staging, and production means a laptop compromise is a production compromise. Use distinct credentials per environment.

Sharing secrets in chat and email

Messages persist, get searched, and get forwarded. You cannot revoke a copy that you do not know exists. Share access to a store instead of the value itself.

Giving everyone production access

Convenience tends to win over least privilege. Limit production credentials to the people and systems that operate it, and review the list when people change roles or leave.

Putting secrets behind a public prefix

Variables prefixed NEXT_PUBLIC_ or VITE_ are embedded in client bundles. Anything there is readable by every visitor.

Logging configuration

Printing the full environment or request headers during debugging puts credentials into log systems with different, usually looser, access. Redact known secret keys and avoid dumping whole objects.

Baking secrets into images

Values passed with Docker ENV or ARG can be recovered from image layers and history. Provide secrets at run time instead.

Never rotating, or rotating without a plan

Credentials that never change keep every past leak alive. But rotating blindly can cause outages. Know where each secret is used, prefer providers that allow two active keys during a transition, and rehearse the change in staging.

Having no record of access

Without an audit trail you cannot answer who read a key, or whether a former employee used theirs. Prefer tools that log reads, changes, and denied attempts. See audit logging.

Treating a deleted secret as a safe secret

Removing a leaked value from a file does not invalidate it. Revoke or rotate it at the provider. Keep that as the first step in every incident. The OWASP Secrets Management Cheat Sheet covers further controls.