How to keep API keys out of your frontend

Why can't a key be hidden in the browser?

Everything the browser runs, the visitor can read: the bundled JavaScript, the network requests, the memory in the developer tools. Minification renames variables; it does not hide strings. Encoding a key only means an attacker copies your decoding function too.

What does the fix look like?

// component.tsx (runs in the browser)
const res = await fetch("https://api.provider.com/v1/send", {
  headers: { Authorization: `Bearer ${import.meta.env.VITE_PROVIDER_KEY}` },
});

// send.functions.ts (runs on the server)
export const send = createServerFn({ method: "POST" })
  .inputValidator((data) => schema.parse(data))
  .handler(async ({ data }) => {
    const key = process.env.PROVIDER_KEY;
    if (!key) throw new Error("PROVIDER_KEY is not set");
    const res = await fetch("https://api.provider.com/v1/send", {
      method: "POST",
      headers: { Authorization: `Bearer ${key}` },
      body: JSON.stringify(data),
    });
    if (!res.ok) throw new Error(`Provider failed [${res.status}]: ${await res.text()}`);
    return res.json();
  });

The endpoint you just created is now the thing that needs protecting: validate its input, and check who is calling it if the action costs money or touches private data.

How do I check what is actually exposed?

1. 1Open your live site, then view the page source and the bundled JavaScript files.
2. 2Search those files for your key's first several characters, and for prefixes like sk_ and service_role.
3. 3Open the Network tab and inspect the request headers your browser sends to third parties.
4. 4Search your repository — including old commits — for the same strings.
5. 5Check your provider's usage dashboard for traffic you cannot explain.

A key found in any of those places is compromised. Rotate it first, then fix the code — in that order.

Which keys are meant to be public?

Publishable and anonymous keys are designed to be seen, and the protection lives in server-side rules such as database access policies. Seeing one in your bundle is expected and fine. The danger is assuming the same about a secret key because both arrived in the same email.

How do you keep it from happening again?

• Name secrets without a public prefix so a build tool refuses to expose them.
• Read secrets only inside server functions, never in shared modules.
• Fail loudly when a secret is missing, so misconfiguration is obvious.
• Enable your provider's secret scanning on the repository.
• Review any AI-generated code that adds a new integration — that is where it slips in.