DEV Community

ke jia
ke jia

Posted on

5 Secrets Developers Accidentally Commit — and the 1 Command That Finds Them

#javascript #node #security #devops

I have audited enough repos to keep a short list of the secrets that show up over and over. Same five, every time.

Here they are — and the one command that finds all of them in your project.

The Usual Suspects

1. The Database URL

DATABASE_URL=postgres://admin:s3cret@db.internal:5432/production

This one is the worst because it carries username, password, host, and schema in a single line. One commit, and an attacker has the map to your data.

2. The API Key

API_KEY=sk_live_... or STRIPE_SECRET_KEY=sk-...

Usually committed because the developer thought "I will rotate it after the demo." The demo happened. The rotation did not.

3. The JWT / Auth Secret

JWT_SECRET=change-me-in-production

Sometimes the value is literally a placeholder. Sometimes it is the real one. Either way, the token-signing key in a public repo means anyone can mint valid tokens for your users.

4. The Private Key

A full BEGIN OPENSSH PRIVATE KEY block, pasted in because "the deploy script needs it and I am in a hurry."

5. The "Long String That Looks Like Nothing"

A 40-character quoted blob. No label. No context. Could be a signing secret, could be a webhook token. In my experience: it is a secret, and it is in the repo now.

The 1-Command Check

DotGuard scans a directory for .env files and flags every one of the patterns above — line numbers included:

npx @wuchunjie/dotguard .
Enter fullscreen mode Exit fullscreen mode 
  🔍  Scanning: /home/dev/app

  📄  .env (3 issues)
    ⚠️  L  3 | API key
       API_KEY=sk_live_abc123...
    ⚠️  L  7 | Database URL
       DATABASE_URL=postgres://admin:***@db.internal:5432/app
    ⚠️  L 11 | Access token
       JWT_SECRET=9f8a7b6c5d4e...

  ⚠️   3 potential secrets exposed!
  💡  Add .env to .gitignore & use .env.example instead.
Enter fullscreen mode Exit fullscreen mode

Zero dependencies, zero config, runs with npx — no install step. And it exits non-zero when it finds issues, so it drops into CI or a pre-commit hook without any extra work.

When It Finds Something

The order matters:

  1. Rotate the secret first — in the provider's dashboard. A leaked key is compromised the moment it is found; deleting it from the repo does not un-leak it.
  2. Move the value out — .env goes in .gitignore, .env.example with empty values goes in the repo.
  3. Clean the history — if it was pushed, it is in the history. Rewriting history (or just nuking the repo and re-cloning, for small projects) closes the door.

Scan, rotate, clean. In that order.

npm: @wuchunjie/dotguard | GitHub: wuchunjie00/devtools

From the same toolbox

  • ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
  • DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
  • GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
  • SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

Top comments (0)