How to Fix Exposed API Keys in 5 Minutes

Quick answer: To fix exposed API keys, immediately revoke the key at the provider dashboard to stop exploitation. 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 to prevent future leaks.

By Daniel A · Kraftwire Software

To fix exposed API keys in code, you must immediately revoke the key at the provider dashboard, audit usage logs for unauthorized activity, move the logic to a server-side proxy (such as a Supabase Edge Function or Next.js API route), and store the replacement key as a secure environment variable without a public prefix. Simply deleting the code or rewriting git history is insufficient because the credential remains active and compromised until it is invalidated by the issuer.

Exposed API keys in code are a primary vector for financial loss and data breaches in the modern development landscape. In SimplyScan's scans of 178 AI-built apps, 59 apps (33%) had at least one HIGH or CRITICAL severity issue, often stemming from secrets leaked in frontend bundles. If you have discovered a secret key in your client-side code, follow this emergency response guide to secure your application in under five minutes.

You Found an Exposed Key. Now What?

Finding an OpenAI, Stripe, or AWS secret key in your frontend JavaScript bundle is a critical security event. This often happens in the "vibe-coding" era · where developers use tools like Lovable, Bolt.new, and Cursor to build apps rapidly. AI coding assistants frequently default to client-side implementations to "make it work" quickly, inadvertently placing sensitive credentials in files that Vite, Webpack, or Turbo bundle for public delivery.

According to proprietary data from SimplyScan, security issues (high) appeared in 20 apps (11%) out of a 178-app sample, frequently involving these types of leaks. Automated bots scan the GitHub "Public Feed" and live websites in real-time; once a key is exposed, it is typically exploited within seconds.

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

The first priority is to stop the bleeding. Do not start by editing your code or cleaning your git history. Go directly to the service provider's dashboard to invalidate the credential.

• OpenAI / Groq: Navigate to the API Keys section of your dashboard (e.g., platform.openai.com or the Groq Console). Click the delete or trash icon next to the compromised key. For Groq API keys, ensure you check both personal and organization-level keys.
• Stripe: Access Developers > API Keys. Use the "Roll Key" feature. Stripe allows you to set an expiration window (e.g., 24 hours) for the old key, but if the leak is public, you should expire it immediately.
• Supabase: If you leaked the service_role key, go to Project Settings > API and regenerate it. Note that this will immediately break any backend services using that key until they are updated.
• AWS: Open the IAM Console, locate the specific user, and set the Access Key status to "Inactive" or "Deleted."
• Anthropic: Visit the Console settings and delete the compromised key immediately.

Step 2: Audit for Unauthorized Usage (1 Minute)

Revocation stops future abuse, but you must determine if the key was used to access data or incur costs before you caught it.

• Billing Anomalies: Check your usage graphs for OpenAI, Anthropic, or Groq. A vertical spike in token consumption that does not align with your actual user traffic is a definitive sign of bot exploitation.
• Resource Creation: In AWS, Google Cloud, or Azure, check for new compute instances, storage buckets, or IAM users in regions you do not typically operate in.
• Data Access Logs: In Stripe, review the "Logs" section for GET requests to sensitive endpoints like /v1/customers or /v1/charges that originated from unfamiliar IP addresses.
• Database Integrity: If a Supabase service_role key was exposed, audit your database logs for DELETE or UPDATE operations on tables containing PII (Personally Identifiable Information).

If PII was accessed, you may have a legal obligation under GDPR or CCPA to notify affected users. SimplyScan's GDPR compliance signals can help identify if your app is currently meeting these reporting standards.

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

The root cause of exposed API keys in code is architectural. In modern web apps, any code in the src directory that is imported into a frontend component will be visible to anyone who views your site's source or inspects network traffic. Architecture issues (medium) appeared in 81 apps (46%) of the 178 apps scanned by SimplyScan, highlighting how common this mistake is.

To fix this, you must implement a Server-Side Proxy. This ensures the secret key never leaves your secure server environment.

Example: Supabase Edge Function

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

Example: Next.js API Route

If you are using Bolt.new or a standard Next.js stack, use an API route:

Step 4: Secure Environment Variables (30 Seconds)

Once your logic is server-side, you must store the new API key in your platform's secret manager.

The Prefix Rule:

• NEVER use VITE_, NEXT_PUBLIC_, or REACT_APP_ for secret keys. These prefixes explicitly tell the build tool to inject the value into the public browser bundle.
• ALWAYS use plain names like STRIPE_SECRET_KEY or GROQ_API_KEY. These remain accessible only to the server-side runtime.

For detailed instructions on managing these, see our guide on environment variables security. Ensure you add these secrets in the "Settings" or "Secrets" tab of Vercel, Netlify, or Supabase, rather than hardcoding them in a .env file that might be accidentally committed to GitHub.

Step 5: Prevent Future Leaks (1 Minute)

To prevent a recurrence, implement automated guardrails that catch secrets before they are deployed.

• Local Pre-commit Hooks: Use tools like gitleaks or trufflehog to scan your local commits. These tools prevent you from pushing code if they detect a string that looks like an API key.
• SimplyScan Automated Audits: Our free security scanner detects exposed API keys, env-var leaks, and missing Supabase RLS in about 30 seconds. It is specifically tuned for AI-built apps that often lack traditional security middleware.
• Gitignore Hygiene: Use our gitignore generator to ensure your .env and node_modules are never tracked by version control.
• Least Privilege: Use restricted API keys where possible. For example, if a key only needs to upload files to S3, do not give it full AdministratorAccess.

Common Mistakes During Remediation

1. Relying on Git History Deletion

Many developers attempt to use git rebase or git filter-repo to remove the secret from their history. While this is good for long-term hygiene, it does nothing to secure the key. Scrapers monitor the GitHub events API; if a key was public for even one second, it is compromised. Revocation is the only fix.

2. Confusing Public vs. Private Keys

Some keys are meant to be public. For example, Stripe's pk_ (publishable) keys and Supabase's anon keys are safe for the frontend. However, Stripe's sk_ (secret) keys and Supabase's service_role keys must never be exposed. If you are unsure, check our API security best practices.

3. Client-Side Domain Restrictions

Providers like Google Maps allow you to restrict a key to a specific domain. While this adds a layer of defense, it is not a substitute for server-side proxying for high-value secrets like OpenAI or Groq keys, as headers can be spoofed in non-browser environments.

The 5-Minute Fix Checklist

• 0:00 · Revoke the compromised key at the provider dashboard.
• 0:30 · Audit billing and usage logs for unauthorized activity.
• 1:30 · Create a server-side API route or Edge Function to handle the request.
• 3:30 · Update the frontend to call your internal proxy instead of the third-party API.
• 4:00 · Save the new key in your deployment platform's Secret Manager (without public prefixes).
• 4:30 · Run a SimplyScan to verify the fix and check for other hidden leaks.

How to Verify Your Fix

After implementing the server-side proxy, you must verify that the key is no longer leaking.

• Open your application in a browser and press F12 to open Developer Tools.
• Navigate to the Network tab.
• Perform the action that triggers the API call.
• Click on the request and inspect the Headers and Response.
• If you see your API key (e.g., a string starting with sk-) in the request headers or body, the key is still exposed. You should only see the data payload being sent to your own domain.

For a deeper audit, use our Secret Scanner or Exposed Files Scanner. These tools search for common misconfigurations that AI tools often introduce, such as leaving .env files accessible via public URLs or exposing node_modules through misconfigured static routing.

Summary: Security in the Vibe-Coding Era

Building at the speed of thought with AI is a superpower, but it requires a shift in how we handle security. AI will often take the path of least resistance, which usually involves placing all logic in a single frontend file. As a developer, your role is to provide the architectural guardrails that the AI might overlook.

Don't let an exposed API key derail your project. By moving secrets server-side and using environment variables correctly, you protect your infrastructure and your users.

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.