How to Fix Exposed API Keys in 5 Minutes

Quick answer: Revoke the exposed key at the provider dashboard immediately to stop exploitation. Then, audit usage logs for abuse, move the API call to a server-side proxy (like an Edge Function), and store the new key as a secure environment variable without public prefixes. Act fast to prevent financial loss.

By Daniel A · Kraftwire Software

To fix exposed API keys, you must immediately revoke the key at the provider dashboard, check usage logs for unauthorized activity, move the logic to a server-side proxy (like a Supabase Edge Function or Next.js API route), and store the replacement key as an environment variable without a public prefix. Deleting the key from your code is insufficient because it remains in your git history and browser caches; only revocation stops active exploitation.

You Found an Exposed Key. Now What?

You just ran a security scan or received an automated alert from GitHub or your cloud provider. You discovered an OpenAI, Stripe, or AWS secret key sitting in your frontend JavaScript bundle. This is a critical emergency, but it is manageable.

The "vibe-coding" era · building apps rapidly with tools like Lovable, Bolt.new, and Cursor · makes it easier than ever to accidentally "leak" a secret by asking the AI to "connect to this API" without specifying a backend architecture. If you act within the next 5 minutes, you can prevent financial loss and data breaches.

Step 1: Revoke the Key at the Provider (30 Seconds)

Before you touch your code, you must kill the credential. Every second an active key remains on the internet, automated bots are attempting to use it for crypto mining, spam, or data scraping. Do not waste time opening your IDE yet. Go straight to the source.

• OpenAI: Navigate to platform.openai.com, go to API Keys, and click the trash icon next to the leaked key.
• Stripe: Go to the Dashboard, then Developers > API Keys. Click "Roll Key" on the secret key. This provides a 24-hour window where the old key still works (optional) or you can expire it immediately.
• Supabase: In Project Settings > API, regenerate the service_role key. Note: This will break existing backend services until you update their env vars.
• AWS: Open the IAM Console, find the User, go to Security Credentials, and set the Access Key to "Inactive" or "Deleted."
• Anthropic: Go to the Console, Settings, and delete the compromised key.

However, you cannot rely on automated systems to catch every leak. You must be the first responder.

Step 2: Audit for Unauthorized Usage (1 Minute)

Revoking the key stops the bleeding, but you need to know if you are already "in the red." Check the following dashboards immediately:

• Billing Spikes: Look at OpenAI or Anthropic usage graphs. If you see a vertical line of usage that doesn't match your traffic, a bot has found your key.
• New Resources: In AWS or Google Cloud, check for new EC2 instances or Lambda functions in regions you don't typically use (e.g., us-east-1 if you are based in Europe).
• Data Exports: In Stripe, check the "Logs" section to see if any GET requests were made to /v1/customers or /v1/charges that didn't originate from your server.
• Database Integrity: If a Supabase service_role key was leaked, check your audit logs for DELETE or UPDATE commands on sensitive tables.

If you find evidence of a breach, you may need to trigger your incident response plan, which includes notifying users if PII (Personally Identifiable Information) was accessed.

Step 3: Move the Secret Server-Side (2 Minutes)

The reason the key was exposed is that it was placed in the "Client Side" of your application. In modern web development, anything in your src folder that gets bundled by Vite, Webpack, or Turbo is visible to the world.

To fix this, you must use a Server-Side Proxy. This is a small piece of code that runs on a server (or Edge Function), holds the secret securely, and makes the API call on behalf of the frontend.

Example: Supabase Edge Function (Deno)

If you are using Lovable or Supabase, move your logic to an Edge Function:

Example: Next.js API Route

If you are using Bolt.new or a standard Next.js stack:

By using these patterns, your frontend only ever talks to yourdomain.com/api/proxy. The actual API key never leaves the server environment.

Step 4: Secure Environment Variables (30 Seconds)

Once the logic is server-side, you need to store the new key. Every platform has a "Secrets" or "Environment Variables" section.

The Golden Rule of Prefixes:

• DO NOT use VITE_, NEXT_PUBLIC_, or REACT_APP_ for secret keys. These prefixes are designed to "leak" the variable into the browser bundle.
• DO use plain names like STRIPE_SECRET_KEY or OPENAI_API_KEY.

If you are using Lovable or Bolt, ensure you add these secrets in the platform's deployment settings (e.g., the "Secrets" tab in Supabase or the "Environment Variables" in Vercel). Never hardcode them in a .env file that is committed to GitHub.

Step 5: Prevent Future Leaks (1 Minute)

To ensure this doesn't happen again, you need automated guardrails. AI coding assistants are prone to "hallucinating" that a frontend-only architecture is safe for secrets.

• Install GitLeaks: A tool that scans your local commits for secrets before they ever reach GitHub.
• Use SimplyScan: Our free security scanner detects exposed API keys, missing Supabase RLS, and env-var leaks in ~30 seconds.
• If a key leaks, the damage is capped.
• Add a .gitignore: Ensure your .env and .env.local files are explicitly ignored. Use our gitignore generator to get a secure baseline.

Common Mistakes During Remediation

1. Deleting the commit but not the key

Many developers try to git rebase or delete the commit containing the key. While this cleans up your history, the key is already in the hands of scrapers who monitor the GitHub "Public Feed" in real-time. You must revoke the key at the provider level regardless of what you do with your git history.

2. Using "Client-Side" Restrictions as a substitute for Secrets

Some providers (like Google Maps) allow you to restrict keys to specific domains. While helpful, this is not a substitute for keeping secret keys (like OpenAI) server-side. Domain restrictions can be spoofed by attackers using custom headers.

3. Forgetting the "Service Role" Key

In the Supabase ecosystem, the anon key is safe for the frontend, but the service_role key bypasses all Row Level Security (RLS). If you accidentally used the service_role key in your frontend code, your entire database is publicly readable and writable. Check our Supabase security checklist for more on this.

The 5-Minute Fix Checklist

• 0:00 · Revoke the key at the provider dashboard.
• 0:30 · Check usage logs for spikes or unauthorized calls.
• 1:30 · Create a server-side API route or Edge Function.
• 3:30 · Move the logic to the server and update the frontend to call your new endpoint.
• 4:00 · Store the new key in your platform's Secret Manager (no public prefixes).
• 4:30 · Run a SimplyScan to verify no other keys are lurking in your bundle.

How to Verify Your Fix

After implementing the proxy, open your website and press F12 to open Developer Tools.

• Go to the Network tab.
• Trigger the action that uses the API.
• Click on the request in the list.
• Look at the Headers and Payload.
• If you see your API key anywhere in the request headers or the body, the fix is not complete. You should only see the data being sent to your own server, not the credential itself.

For a more thorough check, use our Secret Scanner or Exposed Files Scanner. These tools look for common misconfigurations that AI tools often introduce, such as leaving .env files accessible or exposing node_modules via misconfigured static routing.

Summary: Security in the Vibe-Coding Era

Building apps at the speed of thought with AI is incredible, but it shifts the responsibility of architecture onto the developer. AI will often take the "path of least resistance," which usually means putting everything in one file · including your secrets.

Don't let an exposed API key be the reason your project fails. By moving secrets server-side and using environment variables correctly, you protect your users and your bank account.

Run a free scan to check for exposed keys now

Related Guides

• Why Exposed API Keys Are Dangerous
• Supabase RLS Policies Explained
• Next.js Security Guide
• Bolt.new Security Best Practices
• Is Lovable Safe for Production?

Related Free Tools

• Secret Scanner · Detect keys in code snippets
• JWT Debugger · Inspect your auth tokens
• Security Headers Checker · Verify your site's defense-in-depth
• API Key Generator · Create secure, high-entropy keys

faq:

• q: How much can an exposed OpenAI key cost me?

a: Unauthorized usage can scale rapidly. Bots typically discover exposed keys within minutes and can generate hundreds of dollars in charges per hour by running high-token-count completions. Always set a hard billing limit in your OpenAI account settings and revoke any exposed key immediately to stop the financial bleeding.

• q: Do I need to rewrite my git history after leaking a key?

a: While revoking the key is the only way to ensure security, rewriting history with tools like BFG Repo-Cleaner or git filter-repo is good hygiene. It prevents future developers from accidentally re-activating an old key or seeing sensitive metadata. However, never assume a key is "un-leaked" just because you deleted the commit.

• q: Is a Stripe publishable key exposed in frontend code a problem?

a: No. Stripe publishable keys (starting with pk_) and Supabase anon keys are designed to be public. They are used to identify your account but do not allow sensitive actions like issuing refunds or deleting data. Only secret keys (starting with sk_) and service_role keys must be hidden.

• q: What is a server-side proxy and why do I need one for API keys?

a: A server-side proxy is an intermediary endpoint (like a Next.js API route) that sits between your frontend and the third-party API. Your frontend sends a request to your server, your server adds the secret key from a secure environment variable, and then forwards the request. This keeps the key invisible to the user.

• q: How often should I rotate API keys?

a: For high-security applications, rotate keys every 90 days. For vibe-coded or AI-built apps, you should rotate keys immediately after any major architectural change or if you notice unusual traffic patterns. Using separate keys for development, staging, and production environments also limits the impact of a single leak.

• q: How do I know if my app is currently leaking API keys?

a: You can manually check your network tab in browser dev tools or search your build artifacts for strings like "sk-". Alternatively, use SimplyScan for a 30-second automated check. We scan your frontend bundles, network requests, and common file paths to identify exposed secrets before attackers do.

excerpt: Revoke the exposed key at the provider dashboard immediately to stop exploitation. Then, audit usage logs for abuse, move the API call to a server-side proxy (like an Edge Function), and store the new key as a secure environment variable without public prefixes. Act fast to prevent financial loss.

meta_description: Fix exposed API keys in 5 minutes. Learn how to revoke compromised keys, move secrets server-side, and prevent future leaks in AI-built web apps.

meta_title: How to Fix Exposed API Keys in 5 Minutes · SimplyScan

title: How to Fix Exposed API Keys in 5 Minutes