DEV Community

ke jia
ke jia

Posted on

I Audited 50 GitHub Repos - Here Are the 3 Security Mistakes Everyone Makes

#security #github #tutorial #node

I Audited 50 GitHub Repos — Here Are the 3 Security Mistakes Everyone Makes

After scanning 50+ open-source repos with dotguard, I found the same 3 mistakes over and over again.

Here they are — and how to fix them before your API key leaks.

Mistake #1: Hardcoded API Keys in Source Code 

// DON'T do this
const apiKey = "sk-abc123def456ghi789"
const dbPassword = "super_secret_password_123"
Enter fullscreen mode Exit fullscreen mode

This is the #1 cause of security breaches in open-source projects. Someone copies your code, runs it, and suddenly your AWS keys are exposed.

The Fix: Use .env Files 

// DO this instead
require('dotenv').config()
const apiKey = process.env.API_KEY
Enter fullscreen mode Exit fullscreen mode

But here's the catch: .env files get committed to git anyway, because nobody adds them to .gitignore.

That's why I built dotguard — it scans your entire project for exposed secrets before they leak.

npm i -g @wuchunjie/dotguard
dotguard
Enter fullscreen mode Exit fullscreen mode

Mistake #2: No .gitignore for Sensitive Files

Most developers ignore node_modules/, .DS_Store, and dist/. But they forget:

# Missing from .gitignore:
.env
.env.local
*.pem
*.key
config/database.yml
Enter fullscreen mode Exit fullscreen mode

The Fix: Add These to .gitignore 

.env
.env.*
!/.env.example
*.pem
*.key
*.p12
*.pfx
secrets.json
local-settings.php
Enter fullscreen mode Exit fullscreen mode

Pro tip: Run dotguard before every commit. It catches what .gitignore misses.

Mistake #3: Committing Credentials to Git History

Even after you remove the key from the code, it's still in your git history. Anyone who clones the repo can still find it:

git log -p | grep "api_key"
# Boom. Your key is exposed.
Enter fullscreen mode Exit fullscreen mode

The Fix: Use BFG Repo-Cleaner or git filter-branch 

# Install BFG
bfg --replace-text secrets.txt my-repo.git

# Or use git-filter-repo (recommended)
git filter-repo --replace-text secrets.txt
Enter fullscreen mode Exit fullscreen mode

Better approach: Use environment variables from the start. Never commit secrets.

Bonus: How to Scan Your Project Automatically

Add dotguard to your CI/CD pipeline:

# GitHub Actions
- name: Scan for secrets
  run: npx @wuchunjie/dotguard --path . --report json > security-report.json
Enter fullscreen mode Exit fullscreen mode

This runs on every PR. If a secret is found, the build fails.

Why This Matters for Open-Source Developers

Your code is public. Your secrets shouldn't be.

I found production database passwords, AWS keys, Slack tokens, and Stripe keys in public repos. Some had been exposed for months before anyone noticed.

Don't be that person.

  1. Use .env files
  2. Add sensitive files to .gitignore
  3. Run dotguard before every commit
  4. Rotate any keys you've ever committed

Deploy Your Project Securely

Once your code is clean and your secrets are safe, deploy it. I use DigitalOcean for my open-source projects — $200 free credit on signup, no credit card needed.

Free tools I use:

☕ Buy me a coffee | ☁️ Get $200 free hosting

security #github #tutorial #nodejs #devops

Top comments (0)