What Is a Hardcoded Secret? The Credential You Should Never Commit
A hardcoded secret is a password, key, or token written straight into source code or config, where anyone with repo access (or git history) can read it.
Hardcoding a secret feels convenient: paste the key, ship the code, move on. The problem is that source code spreads. It is cloned, forked, backed up, and kept in history forever. Once a secret is committed, it is effectively public to everyone who can reach the repo, and removing it from history is painful.
What it looks like
A hardcoded secret is an API key in a JavaScript file, a database password in a YAML config, or a token in a shell script committed to the repo. It is any credential that lives in version control instead of being injected at runtime.
Why it is dangerous
- Anyone with read access to the repo can use it.
- It persists in git history even after you delete the line.
- Forks, clones, and backups copy it everywhere.
- Public repos expose it to automated scanners within minutes.
The git history trap
Deleting a hardcoded secret in a new commit does not remove it; the old value still sits in history and is trivially recoverable. The only real fixes are to rotate the secret (assume it is burned) and, if necessary, rewrite history, which is disruptive.
How to avoid it
Inject secrets at runtime from environment variables or a secrets manager, never from committed files. Add patterns for key files to .gitignore, and use secret scanning to catch mistakes before they merge.
Catching them automatically
Secret scanners run in CI and on every push, flagging anything that looks like a credential. Combined with a pre-commit hook, they stop most hardcoded secrets before they ever reach a shared branch.
Key takeaways
- A hardcoded secret is a credential committed to source code or config.
- It persists in git history forever and spreads through clones and forks.
- Inject secrets at runtime and use scanning to block them before merge.