Exposed API keys: what they are, and how to find and fix yours

Public keys vs secret keys, the distinction that matters

Quick rule: "pk_" and "anon" are meant to be public. "sk_", "service_role", and anything called "secret", "private", or "password" are not, if one is in your browser, treat it as compromised.

Where AI tools leak secret keys

• The "NEXT_PUBLIC_" prefix trap: in Next.js, any environment variable named "NEXT_PUBLIC_..." is deliberately baked into the browser bundle. AI tools sometimes prefix a secret this way to "fix" it being undefined on the client, which publishes it to the world.
• Hardcoded in frontend code: the key is pasted directly into a component or client-side file because that is where the code calling the service lives.
• The built JavaScript bundle: even without "NEXT_PUBLIC_", a secret imported into client code gets bundled and shipped. Viewing source or the network tab reveals it.
• A committed ".env" file: the real ".env" (with actual values) gets committed to the repo instead of being ignored, so anyone with repo access reads every secret.
• Git history: a key was committed once, then removed in a later commit. It looks gone, but it lives on in history forever and is still readable.
• Client-side calls to third-party APIs: calling OpenAI, Resend, or a similar service directly from the browser forces the secret into the client, where it cannot be hidden.

How to find your exposed keys, step by step

1. Open your live site, right-click, choose "Inspect", and open the "Sources" (or "Debugger") tab to see the loaded JavaScript.
2. Search the loaded files for "sk_", "service_role", "secret", "api_key", and the names of services you use (e.g. "openai", "sk-"). Anything that matches a secret key is exposed.
3. Open the "Network" tab, use your app normally, and inspect outgoing requests, a secret sent from the browser to a third-party API is exposed.
4. In your codebase, search for "NEXT_PUBLIC_" and confirm every one of them is genuinely safe to be public; a secret behind that prefix is exposed.
5. Check whether a real ".env" file is tracked by git (it should be listed in ".gitignore" and not appear in the repo).
6. Search your git history for secrets, for example "git log -p -S sk_", a key that was committed and later deleted is still there. GitHub also sends secret-scanning alerts if it detects known key formats. [SOURCE NEEDED]

How to rotate a leaked key safely

How to keep secrets server-side for good

// ❌ WRONG, secret key shipped to the browser
// This runs on the client, so the key is in the bundle for anyone to read.
const res = await fetch('https://api.openai.com/v1/...', {
  headers: { Authorization: `Bearer sk_live_REAL_SECRET_KEY` },
});

// ✅ RIGHT, the browser calls YOUR endpoint; the secret never leaves the server.
// Client code:
const res = await fetch('/api/generate', { method: 'POST', body });

// Server code (e.g. a Next.js API route / server action / Edge Function):
// process.env.OPENAI_API_KEY is read only here, never sent to the client.
const apiKey = process.env.OPENAI_API_KEY; // secret, server-side only
// ... use apiKey to call the third-party API, return only the result