Ask any security researcher where they start when poking at a small app and the answer is boring: they search the code and the shipped bundle for things that look like secrets. It works far more often than it should.
Why hardcoded secrets are so common
You are moving fast. You paste a Stripe key or an OpenAI token inline to make something work, promise yourself you will move it to an environment variable later, and later never comes. Then the repo goes public, or the key ships inside your JavaScript bundle, and it is live on the internet.
Where they hide
- Inline in source files, especially config and API-client setup.
- In the production build output (the bundle), even when the source uses an env var incorrectly.
- In git history, committed once and "removed" later but still recoverable.
- In
.envfiles that got committed by accident.
Pattern matching is not enough
Known prefixes (like sk_live_ for Stripe) are easy to flag. The dangerous ones are the generic high-entropy strings: a random 40-character token with no recognizable prefix. Catching those needs entropy analysis, not just a keyword list.
If a secret ever touched your code, assume it is compromised and rotate it. Removing it from the current file is not enough.
Getting them out
Move every secret to an environment variable, add .env to .gitignore, and rotate anything that was ever committed. Then scan the built bundle, not just the source, because that is what actually ships to users. A good secret scan checks both, and flags the high-entropy strings a keyword list would miss.