How to Hide API Keys in Vite/React

Vite only exposes env variables that start with VITE_ to your client code, via import.meta.env. And it doesn't look them up at runtime: it replaces them with their actual values when you build. So the string ends up in a .js file that every visitor downloads.

# .env
VITE_SUPABASE_URL=https://xyz.supabase.co   # exposed to the client
OPENAI_API_KEY=sk-...                         # not exposed to client code

// in your React code
import.meta.env.VITE_SUPABASE_URL  // "https://xyz.supabase.co"
import.meta.env.OPENAI_API_KEY     // undefined

Vite's own docs say VITE_* variables shouldn't contain sensitive information like API keys, and suggest a backend server or serverless/edge functions instead. Minifying or obfuscating doesn't change this; a key is still a plain string in the bundle. Don't widen envPrefix in your Vite config to sneak other variables in, either. That just exposes more.

Dropping the prefix doesn't magically make a key usable, by the way. OPENAI_API_KEY above is undefined in the browser. Code that needs it has to run on a server.

Rule of thumb: if the provider's docs call it a "secret" key, or using it costs you money or bypasses permissions, it goes on a server. The anon key is only safe because of Row Level Security, so make sure that's actually set up: the Supabase RLS checklist.

If you already use Supabase (most Lovable and Bolt apps do), this is usually the easiest path. Store the secret as an Edge Function secret, then call the function from React.

supabase secrets set OPENAI_API_KEY=sk-...

// supabase/functions/ask-ai/index.ts (sketch)
const corsHeaders = {
  "Access-Control-Allow-Origin": "https://your-app.com", // your app's origin
  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
  "Access-Control-Allow-Methods": "POST, OPTIONS",
};

Deno.serve(async (req) => {
  // browsers send a CORS preflight before supabase.functions.invoke()
  if (req.method === "OPTIONS") {
    return new Response("ok", { headers: corsHeaders });
  }
  // 1. verify the caller (check the Authorization header / user session)
  // 2. validate and limit the input, and rate-limit per user
  const { prompt } = await req.json();
  const r = await fetch("https://api.openai.com/v1/responses", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${Deno.env.get("OPENAI_API_KEY")}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ model: "<model>", input: prompt }),
  });
  if (!r.ok) {
    // don't pass raw upstream errors back to the browser
    return new Response(JSON.stringify({ error: "AI request failed" }), {
      status: 502,
      headers: { ...corsHeaders, "Content-Type": "application/json" },
    });
  }
  return new Response(await r.text(), {
    headers: { ...corsHeaders, "Content-Type": "application/json" },
  });
});

// React: the browser only ever talks to your function
const { data, error } = await supabase.functions.invoke("ask-ai", {
  body: { prompt },
});

Edge Functions read secrets with Deno.env.get(). Locally they come from supabase/functions/.env (keep it in .gitignore). Supabase also injects its own keys, like SUPABASE_URL and the secret/service_role key, so you never need to put those anywhere near your frontend. You can't name your own secrets with a SUPABASE_ prefix; that's reserved. Calls from your React app are cross-origin, so the function has to answer the OPTIONS preflight and send CORS headers on every response, as above. Edge Functions verify a Supabase JWT by default, but the anon key alone passes that check, so still confirm there's a real signed-in user before spending your API credits.

Deploying to Vercel or Netlify? Their serverless functions work the same way: put the secret in the host's environment variables without the VITE_ prefix, read it with process.env inside the function, and have React fetch your own endpoint (for example /api/ask-ai). File locations and setup differ by host, so follow their docs for the details.

Any backend you control (Express, Hono, a Cloudflare Worker) can act as a proxy: it receives the request from your app, adds the secret, forwards it to the API, and returns the result.

Careful with Vite's server.proxy setting. It only runs in the dev server (vite / npm run dev), not in a production build, so it can't hide a key in production. vite build produces static files, and that proxy doesn't exist in production. Putting a key in your proxy config hides it locally and then breaks (or tempts you to move the key back into the frontend) once you deploy.

Moving the key to a server stops it leaking, but anyone can still call your endpoint. Before you ship it:

• Require a signed-in user and check their session on the server.
• Only allow the specific action your app needs (no "forward any URL / any body" endpoints).
• Validate input size, and add rate limits or per-user quotas.
• Set spending limits or alerts in the provider dashboard where they exist.
• Don't return the secret or raw error details in responses.

Removing it from the code isn't enough. Old deploys, caches and git history keep it around. Create a new key in the provider's dashboard, put it on your server, redeploy, then revoke the old one. Check git too: if a .env file was ever committed, treat everything in it as leaked. Vite's docs recommend adding *.local to .gitignore; keep secrets in .env.local files and make sure any .env with real secrets is ignored too.

Leaked a Supabase service_role key specifically? Here's the step-by-step. Not sure what's in your bundle? How to find leaked API keys in your JavaScript.