Exposed API Key: Exactly What to Do in the Next 10 Minutes
Mr. Ballaz- Focus
- API Security
- Risk
- High
- Stack
- Supabase/Next.js
- Detection
- Ubserve Runtime Simulation
Found an exposed API key in your code, GitHub repo, or frontend bundle? Here is the exact step-by-step response to stop the damage, rotate credentials, and prevent it from happening again.
An exposed API key is not just a future risk — it is an active incident the moment the key is in a public place. Here is exactly what to do in the next 10 minutes.

An exposed API key is not a future risk. The moment a key appears in a public GitHub repository, a deployed JavaScript bundle, or an error log, assume it has already been found. Automated scrapers monitor GitHub commits and public JavaScript bundles continuously. Studies have found secrets accessed within minutes of being pushed to a public repo.
If you found an exposed API key — in your code, your git history, your deployed app, or anywhere else — here is exactly what to do in the next 10 minutes.
The 10-Minute Incident Response
Minute 1-2: Revoke the Exposed Key Immediately
Do this before anything else. An invalidated key cannot be abused regardless of where it appears.
OpenAI:
- Go to platform.openai.com → API Keys
- Find the exposed key, click the trash icon
- Confirm deletion
Stripe:
- Go to dashboard.stripe.com → Developers → API Keys
- Click "Roll key" next to the exposed key
- The old key is immediately invalidated
Supabase service role:
- Go to your Supabase project → Settings → API
- Click "Generate new JWT secret" — this rotates both the anon key and service role key
- Update your environment variables immediately after
AWS:
- Go to IAM → Users → Security credentials
- Make the exposed access key Inactive
- Delete it after confirming your new key works
GitHub token:
- Go to github.com → Settings → Developer settings → Personal access tokens
- Delete the exposed token immediately
Minute 2-5: Audit for Unauthorized Usage
Before replacing the key, check if it was used by anyone other than your app.
OpenAI:
- Go to platform.openai.com → Usage
- Check the last 24-48 hours for spikes in usage or requests from unexpected times
- Look for model types you do not use
Stripe:
- Go to dashboard.stripe.com → Events
- Filter for events in the last 48 hours
- Look for API calls you did not make, especially charges or payout changes
AWS:
- Go to CloudTrail → Event history
- Filter by the exposed access key ID
- Look for resource creation, deletion, or IAM changes
Supabase:
- Check your project's log explorer for unusual query patterns
- Look for bulk selects or data exports you did not initiate
Document what you find. If there is evidence of unauthorized usage, this is a data breach — notify affected users.
Minute 5-7: Generate and Deploy the New Key
- Create a new key in the provider's dashboard with the minimum necessary permissions.
- Update your environment variables in your hosting platform (Vercel, Netlify, Railway, Render).
- Redeploy your application so the new key is active in production.
- Verify the app is working correctly with the new key before proceeding.
Minute 7-10: Find and Remove the Key Everywhere
The old key is revoked. Now make sure it cannot come back.
Search your git history:
# Find the key in git history
git log --all -S "your-exposed-key-prefix" --source --format="%H %ai %s"
# If found in history, rewrite it
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch path/to/file' \
--prune-empty --tag-name-filter cat -- --all
# Force push (coordinate with your team first)
git push origin --force --all
Search your current codebase:
# Search for key patterns
grep -r "sk-" . --include="*.js" --include="*.ts" --include="*.env"
grep -r "service_role" . --include="*.js" --include="*.ts"
grep -r "OPENAI_API_KEY" . --include="*.js" --include="*.ts"
Check your deployed JavaScript bundle:
- Open your production URL in a browser
- Open DevTools → Sources (or Network)
- Search the JavaScript files for the key string or its prefix
- If found, the bundle needs to be rebuilt after removing the key from source
Why API Keys Get Exposed in AI-Built Apps
The majority of API key exposures in AI-built apps come from three patterns:
Pattern 1: Frontend API calls with hardcoded keys
AI tools take the fastest path to a working implementation. "Add OpenAI to this app" → direct client-side call with the key in the environment variable. If the variable is prefixed with NEXT_PUBLIC_ or VITE_, it ships in the client bundle.
// This ships the key to the browser in the client bundle
const openai = new OpenAI({
apiKey: process.env.NEXT_PUBLIC_OPENAI_KEY // exposed to every visitor
});
Pattern 2: Keys pasted into AI tool prompts
Pasting a key into Cursor, ChatGPT, or Claude for debugging purposes puts the key into the AI's context. That context may appear in generated code, code comments, or suggestions.
Pattern 3: Committed .env files
Rapid prototyping with .env files that were never added to .gitignore. The file gets committed, the repo gets pushed to GitHub, the key is indexed by GitHub search and third-party scrapers.
How to Prevent This From Happening Again
Rule 1: Server-only keys stay server-only
No paid API key should ever appear in client-side code. In Next.js, this means no NEXT_PUBLIC_ prefix. In Vite, no VITE_ prefix. All paid API calls go through a backend function that holds the key in process.env.
Rule 2: Secret scanning before every commit
Add gitleaks or trufflehog as a pre-commit hook. These tools scan for key patterns before the commit is recorded in git history — the most important place to catch them.
# Install gitleaks
brew install gitleaks # Mac
# or download from github.com/gitleaks/gitleaks
# Run before every commit (or add as pre-commit hook)
gitleaks detect --source . --verbose
Rule 3: Scan your deployed bundle
A key removed from source can still appear in a previously deployed bundle. Run Ubserve's free frontend scan on your production URL — it checks your deployed JavaScript assets for exposed API key patterns across 20+ key formats including OpenAI, Stripe, Supabase, AWS, and more.
Rule 4: Rotate all keys on a schedule
Even keys that have never been exposed should be rotated quarterly. Rotation limits the blast radius of any future exposure — a rotated key from 3 months ago is worthless to an attacker.
What Ubserve Scans For
Ubserve was built specifically for the API key exposure patterns that appear in AI-built apps:
- OpenAI, Anthropic, and Cohere API keys in frontend bundles
- Stripe secret keys and restricted keys in client-side code
- Supabase service role keys and JWT secrets in JavaScript assets
- AWS access keys and secret access keys
- GitHub personal access tokens
- Generic secret and password patterns
The free scan takes 60 seconds and shows you whether any of these are present in your deployed application right now — no code access required.
The fastest response to an exposed API key is always revoke first, investigate second, fix third. Do not spend the first 10 minutes trying to understand how it happened. Revoke the key, then figure out the rest.
— Mr. Ballaz, Founder of Ubserve