Critical 7 min read

You Just Pushed Your API Keys to GitHub. Now What?

Accidentally committed your API keys? Bots are already scanning for them. Here's what to do in the next 5 minutes to avoid a $10,000 surprise bill.

You were coding fast. Built a cool feature with ChatGPT. Added your OpenAI API key to test it. Committed the code. Pushed to GitHub.

Then you realized: Your API key is now public.

Here's what's happening right now:

Bots scan every GitHub commit within seconds of being pushed
They automatically find API keys, tokens, and passwords
They start using them immediately—mining crypto, generating spam, or racking up your bill

This isn't hypothetical. It happens hundreds of times per day.

🚨 If You Just Exposed Keys: Do This NOW

Stop reading and rotate the key immediately (go to the service's dashboard → regenerate/delete)
Check your usage/billing to see if bots already hit it
Remove the key from GitHub history (instructions below)
Never commit secrets again (also below)

Do this before you finish reading this article. Every minute counts.

Real Stories (This Actually Happens)

Story 1: The $72,000 AWS Bill

A developer accidentally committed AWS credentials to a public GitHub repo. Within 20 minutes, bots spun up 500+ EC2 instances to mine cryptocurrency. By the time he noticed, the bill was $72,000.

AWS didn't waive the charges. He had to pay.

Story 2: The OpenAI Account Suspension

A student put their OpenAI API key in frontend code. Bots found it and made 10,000+ requests in an hour. OpenAI suspended the account for abuse. Months of project work lost.

Story 3: The Twilio Scam

Exposed Twilio credentials were used to send 50,000 SMS messages to premium numbers the attacker controlled. Cost: $15,000. The app was still in development—it didn't even have users yet.

These people all thought: "I'll fix it later." Later came with a massive bill.

How Bots Find Your Keys (In Seconds)

Here's what happens when you push code to GitHub:

Second 0: You push code with an API key
Second 1-3: Bots scanning GitHub find your commit
Second 4-10: Automated scripts extract the key and test if it works
Second 11+: If valid, bots start using it (or sell it on dark web forums)

They look for patterns like:

sk_live_ (Stripe keys)
AKIA (AWS access keys)
sk-proj- or sk- (OpenAI keys)
ghp_ (GitHub tokens)
xox (Slack tokens)
And hundreds more patterns for every popular service

Immediate Damage Control (Do This First)

Step 1: Rotate/Delete the Exposed Key

For OpenAI:

Go to platform.openai.com/api-keys
Find the exposed key
Click "Delete" or "Revoke"
Create a new key
Update your local .env file with the new key

For Stripe:

Go to dashboard.stripe.com/apikeys
Click "Delete" on the exposed key
Generate a new key
Check Recent Activity for suspicious charges

For AWS:

Go to IAM console → Users → Security credentials
Delete the exposed access key
Create new credentials
Check CloudTrail for suspicious activity
Review billing dashboard immediately

Step 2: Check If Damage Already Happened

Go to your service's usage/billing dashboard and look for:

Unusual spikes in API calls
Requests from countries you don't operate in
Resources created that you didn't make
Sudden increase in costs

If you see suspicious activity: Contact support immediately and explain what happened. Some providers waive charges for first-time incidents.

Step 3: Remove Keys from Git History

Deleting the file or commit isn't enough—the key is still in your repo's history. You need to purge it completely.

# Use BFG Repo-Cleaner (easiest method)
# Download from: https://rtyley.github.io/bfg-repo-cleaner/

# Replace 'YOUR_API_KEY' with the actual exposed key
bfg --replace-text passwords.txt your-repo

# Or use git filter-repo (more powerful)
git filter-repo --path .env --invert-paths

# Force push to overwrite history
git push --force --all
                

⚠️ Warning: Force Push Breaks Collaborators

If others are working on the repo, coordinate with them first. They'll need to re-clone after you force push.

How to NEVER Make This Mistake Again

1. Use Environment Variables (The Right Way)

Create a .env file in your project root:

# .env
OPENAI_API_KEY=sk-proj-your-secret-key-here
STRIPE_SECRET_KEY=sk_live_your-stripe-key
DATABASE_URL=postgresql://user:password@host/db
                

Add .env to your .gitignore:

# .gitignore
.env
.env.local
.env.production
*.key
*.pem
secrets/
                

Load them in your code:

// Node.js
require('dotenv').config();
const apiKey = process.env.OPENAI_API_KEY;

// Python
import os
from dotenv import load_dotenv
load_dotenv()
api_key = os.getenv('OPENAI_API_KEY')
                

2. Create an .env.example File

This helps other devs know what environment variables they need—without exposing the real values:

# .env.example (safe to commit)
OPENAI_API_KEY=sk-proj-your-key-here
STRIPE_SECRET_KEY=sk_live_your-key-here
DATABASE_URL=postgresql://localhost/myapp
                

3. Use Git Hooks to Block Commits

Install a pre-commit hook that scans for secrets before you commit:

# Install detect-secrets
pip install detect-secrets

# Set up pre-commit hook
detect-secrets scan > .secrets.baseline
detect-secrets audit .secrets.baseline

# Add to .pre-commit-config.yaml
repos:
  - repo: https://github.com/Yelp/detect-secrets
    hooks:
      - id: detect-secrets
                

Now if you try to commit a secret, it'll block you with a warning.

4. Different Keys for Different Environments

Never use production keys in development. Create separate keys for:

Development: Local testing, low rate limits
Staging: Pre-production testing
Production: Real users, restricted permissions

If you leak a dev key, it's less catastrophic than leaking production credentials.

5. Use Secret Management Services

For production apps, use dedicated secret managers:

Vercel/Netlify: Built-in environment variable management
AWS Secrets Manager: For AWS deployments
HashiCorp Vault: For complex setups
Doppler: Works with any platform

Red Flags That Scream "You're Doing It Wrong"

If you see any of these in your code, fix them NOW:

❌ const API_KEY = "sk-proj-abc123..." in your JavaScript files
❌ Committing .env files to git
❌ Hardcoded passwords or tokens anywhere in code
❌ Sharing API keys in Slack/Discord/email
❌ Using the same key across multiple projects
❌ Production keys in screenshot or video tutorials

✅ Quick Test: Can You Answer These?

If your laptop gets stolen, are your production API keys safe?
If you share your code with someone, will they have your secrets?
If a bot scans your GitHub, will it find valid keys?

If the answer to any is "no", fix it today.

Scan Your Code for Exposed Secrets

VibeCheck automatically scans your GitHub repos and finds hardcoded API keys, passwords, and tokens before bots do.

Check My Repo Free →

The Bottom Line

Exposed API keys aren't "just a mistake"—they're a financial and security disaster waiting to happen.

If you exposed keys:

Rotate them immediately
Check billing for suspicious activity
Purge them from git history
Set up environment variables properly

To prevent it forever:

Never commit .env files
Use environment variables for ALL secrets
Install pre-commit hooks to catch mistakes
Use different keys for dev and production

Your future self will thank you when you're not dealing with a $10,000 bill from bots abusing your keys.