How to Fix Exposed API Keys

Quick answer: If a secret API key leaks, revoke it through the provider, investigate its use, and repair the exposure path. Store replacements server-side and test authorized integrations. Deleting a file does not invalidate copied credentials or undo prior access.

By Daniel A · Kraftwire Software

If a secret API key leaks, revoke it through the provider’s supported controls, investigate usage, and repair the exposure path. Keep replacement credentials server-side and test legitimate integrations. Deleting code or rewriting history does not invalidate a copied credential.

A usable leaked credential can expose the data and operations permitted by its scope and can incur usage charges.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

If you discover a client-side secret, revoke it, investigate use, and fix the exposure path. The work required depends on the credential and application.

You Found an Exposed Key. Now What?

Finding a secret in a public bundle requires investigation. Identify the credential, its permissions, and where it was exposed before replacing it through the provider’s controls.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

Do not rely on a short exposure window as evidence that no one copied a key. Review available logs and treat the credential as exposed.

Step 1: Revoke the Exposed Credential

Prioritize disabling the leaked credential and coordinating replacement for legitimate services. Verify revocation rather than assuming a dashboard action has already propagated.

OpenAI / Groq

Use the provider’s current API-key management controls to revoke the exposed key and confirm the result. For OpenAI, review the API authentication documentation; follow Groq’s own key-management instructions for Groq credentials.

Stripe

Use Stripe’s current key-management controls to replace and expire the exposed secret credential. Verify that the old key is no longer accepted and update legitimate integrations.

Supabase

Distinguish a legacy service_role JWT from a newer secret API key. Follow Supabase’s rotation or revocation procedure for that credential type; a legacy signing-secret change can affect other keys and sessions. Update dependent services and test the old credential’s rejection.

AWS

Deactivate or delete the exposed AWS access key using IAM controls, then update authorized workloads and review its activity.

Anthropic

Revoke the exposed key through Anthropic’s key-management controls and verify the result.

Step 2: Investigate Unauthorized Usage

Revocation prevents new authentication with that credential once enforced. It does not undo previous access, already-created resources, or other credentials an attacker may have obtained.

• Usage: Investigate unexplained consumption; a spike alone does not prove bot exploitation.
• Resources: Review unexpected compute resources, storage, accounts, and permission changes.
• API Logs: For Stripe, inspect relevant GET requests, including /v1/customers or /v1/charges, in the context of expected callers.
• Database Activity: If a Supabase service_role credential leaked, investigate relevant reads as well as DELETE and UPDATE operations.

Assess the incident and any notification obligations through your incident-response process. SimplyScan’s privacy/compliance signals do not determine breach-reporting duties or whether notifications meet legal requirements.

Step 3: Repair the Exposure Path

Any credential included in a client bundle can be read by visitors. The directory name src alone does not determine exposure; inspect the code’s execution environment, build configuration, and resulting assets.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

For browser features that need a secret provider key, a server endpoint can make the provider request. It must also authenticate and authorize callers, validate inputs, limit resource use, and avoid leaking secrets through responses or logs.

Example: Supabase Edge Function

This original example shows server-side key loading and an outbound API call for a Lovable or Supabase project. It is incomplete: it omits caller authentication and authorization, input validation, usage limits, and robust error handling. The historical import and model names also require verification before use; do not deploy it as a secure proxy.

Example: Next.js API Route

The original route below also illustrates only server-side key placement. It omits the same access, validation, usage, and error controls; verify the model and endpoint configuration before adapting it to a Next.js project.

Step 4: Configure Secret Storage

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

The Prefix Rule:

• Prefixes such as VITE_, NEXT_PUBLIC_, and REACT_APP_ expose referenced values in the corresponding frontend build systems. Do not use them for secrets.
• Names such as STRIPE_SECRET_KEY or GROQ_API_KEY do not enforce privacy by themselves. Store and load those values only in server-side contexts, then inspect the built output.

Use the deployment platform’s supported server-side secret storage. For local development, keep secret-bearing .env files out of version control and client builds. See environment variables security.

Step 5: Reduce the Risk of Another Leak

Add secret checks to the development workflow and review their coverage. A detector can miss credentials, and a hook can be bypassed.

Local Pre-commit Hooks

Tools such as gitleaks or trufflehog can inspect supported inputs for credential patterns. Configure their checks in hooks or CI if you want detected findings to block changes; installing a tool alone does not prevent a push.

SimplyScan Audits

SimplyScan’s free URL scan checks accessible responses and assets for recognizable secret patterns and environment-file exposure. Supported anonymous backend observations do not establish every RLS policy’s correctness.

Gitignore Hygiene

Review the generated ignore rules for .env and node_modules, and inspect tracked files and history separately. Ignore rules do not remove files already committed or prevent secrets from reaching a client build. See gitignore generator.

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

Tools such as git rebase or git filter-repo can alter repository history, but cannot invalidate copies already taken. Revoke the credential and coordinate cleanup of repositories and other exposed copies. A brief exposure is not proof that no copy exists.

2. Confusing Public and Secret Keys

Stripe pk_ keys and Supabase anon keys are designed for public clients, with authorization enforced by their respective systems. Stripe sk_ secrets and Supabase service_role credentials must stay server-side. A public key does not make an application’s access controls correct. See API security practices.

3. Relying on Client-Side Restrictions

Use the provider’s documented restrictions for a public client key. They do not turn a secret server credential into a safe browser credential. Keep secret provider keys server-side.

Remediation Checklist

• Revoke the exposed credential and verify rejection.
• Investigate usage, permissions, and affected resources.
• Repair the path that exposed it.
• Store the replacement server-side and update authorized integrations.
• Inspect deployed assets and responses, and run supported SimplyScan checks.
• Re-test the affected operations; a clear scan does not prove that every copy or exposure path is gone.

How to Verify Your Fix

After changing the implementation, inspect its deployed behavior:

• Open browser Developer Tools, using F12 where supported.
• Inspect requests and responses for the affected feature.
• Check headers and payloads for secret credentials.
• Search built assets and accessible files too.
• Investigate a key-like pattern such as sk-; a prefix alone does not establish the credential’s type or validity.

The server endpoint may be on a separate origin, and a clean browser observation is not exhaustive evidence.

Use the Secret Scanner for recognizable credential patterns and the Exposed Files Scanner for bounded public-path probes. Separately inspect deployment routing for unintended access to .env files or node_modules; a bounded scan does not enumerate every file. Investigate each result and the areas those checks do not cover.

Summary: Security in the Vibe-Coding Era

Apply the same secret-handling review to generated and manually written code. Test the implementation and deployed assets independently of whether the feature appears to work.

Keep the incident record, confirm that old credentials are disabled, and review how the new controls will be tested after changes.

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 · Check supported inputs for secret patterns.
• JWT Debugger · Decode tokens and inspect supported signature checks.
• Security Headers Checker · Inspect returned response headers.
• API Key Generator · Generate random values for an application you control; it does not issue third-party provider credentials.

Frequently Asked Questions

How much can an exposed OpenAI key cost me?

Usage depends on the credential’s permissions, the services invoked, and applicable limits. Revoke exposed keys and investigate usage. Review the provider’s current budget and alert behavior; do not assume a notification threshold stops requests.

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

Revoke the exposed key first. Rewriting history with git filter-repo or another appropriate tool can remove repository copies, but cannot invalidate copies already taken. Coordinate cleanup with collaborators and inspect other exposure paths.

Is a Stripe publishable key exposed in frontend code a problem?

Stripe pk_ keys and Supabase anon keys are designed for public clients, but their systems still need correct authorization. Stripe sk_ secrets and Supabase service_role credentials must stay server-side. Review the permissions of the actual key type.

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

A server-side proxy accepts an application request and makes the provider call using a server-held credential. It must authenticate and authorize callers, validate inputs, and control resource use. Server placement alone does not prevent leaks through logs or responses.

How often should I rotate API keys?

Revoke a key when it is exposed or otherwise compromised. Plan routine rotation according to the provider, credential type, and organizational policy; there is no universal interval for every application. Test replacement and separate environments where appropriate.

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

Inspect built assets, accessible files, and the relevant browser requests and responses. SimplyScan adds bounded checks for recognizable exposed secret patterns. A clear result does not prove that no credentials are exposed or that an attacker has not already copied a credential.