Ubserve Blog

Exposed API Key: Exactly What to Do in the Next 10 Minutes

Mr. BallazMr. Ballaz
April 25, 20266 min read
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.

Exposed API key incident response guide — what to do immediately after finding a leaked key.
Exposed API key incident response guide — what to do immediately after finding a leaked key.

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:

  1. Go to platform.openai.com → API Keys
  2. Find the exposed key, click the trash icon
  3. Confirm deletion

Stripe:

  1. Go to dashboard.stripe.com → Developers → API Keys
  2. Click "Roll key" next to the exposed key
  3. The old key is immediately invalidated

Supabase service role:

  1. Go to your Supabase project → Settings → API
  2. Click "Generate new JWT secret" — this rotates both the anon key and service role key
  3. Update your environment variables immediately after

AWS:

  1. Go to IAM → Users → Security credentials
  2. Make the exposed access key Inactive
  3. Delete it after confirming your new key works

GitHub token:

  1. Go to github.com → Settings → Developer settings → Personal access tokens
  2. 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.

Run your free scan


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

Related reading

FAQs

What should I do if my API key is exposed?+
Immediately revoke the exposed key in the provider's dashboard, generate a new key, update your environment variables, and scan git history and your deployed bundle to confirm the old key is completely removed.
Is an exposed API key an emergency?+
Yes. The moment an API key is in a public GitHub repo, a deployed JavaScript bundle, or any other accessible location, assume it has already been found. Treat it as an active breach, not a potential one.
How do API keys get exposed?+
The most common causes are: committing .env files to git, hardcoding keys in frontend code that ships in the client bundle, pasting keys into AI coding tools like Cursor or ChatGPT, and logging key values in error messages.
Can I just rotate the key or do I need to do more?+
Rotate the key immediately, but also audit for unauthorized usage before the rotation, remove the key from every location it appeared, and scan your entire codebase and git history for other exposed keys.
How long does it take for an exposed API key to be found by scrapers?+
Studies have found exposed GitHub secrets are accessed within minutes of a commit being pushed. Automated scrapers monitor public repos, npm packages, and deployed JavaScript bundles continuously.
How do I prevent API key exposure in AI-built apps?+
Never put paid API keys in client-side code or NEXT_PUBLIC_ variables. Use server environment variables for all provider keys. Run automated secret scanning before every deploy. Use Ubserve to scan your frontend bundle for exposed keys.
Ubserve Security

We find the vulnerabilities in your app before hackers do.

Exposed secrets, broken access paths, and real attacker-first weaknesses. Get a fast scan and fix-ready guidance without slowing release velocity.