How to find and fix exposed API keys in your AI-built app

Not every key visible in your JavaScript is a breach. Here is exactly how to tell the difference, before you panic-rotate everything or ignore something critical.

The rule that actually matters

Some API keys are built to be public — they identify your project, not authorize privileged actions, and providers design their systems assuming anyone can see them. Others grant real power: spending money, reading private data, deleting resources. Finding a key in your bundle tells you nothing on its own — which category it falls into tells you everything.

Where AI coding tools leak these

The most common pattern: asking your AI coding tool to "connect to OpenAI" or "add Stripe checkout" and it wires the secret key directly into a client component or a fetch call that runs in the browser, because that is the shortest path to something visibly working. It is correct code in the sense that it runs — it is wrong in the sense that anyone who opens devtools now has your key.

The fix

Move the call server-side. In Next.js, that means a Route Handler reading the key from an environment variable that is never prefixed NEXT_PUBLIC_:

// app/api/chat/route.ts — runs server-side, key never reaches the browser
export async function POST(req: Request) {
  const { prompt } = await req.json();

  const res = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`, // server-only env var
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ /* ... */ }),
  });

  return Response.json(await res.json());
}

Your frontend then calls /api/chat on your own domain — the browser never sees the real key. Then rotate the exposed key with the provider immediately; the old one should be treated as fully compromised the moment it was visible.

Common questions

More guides: Supabase RLS: the #1 vibe-coding bug · Full vibe-coding security checklist