Are my API keys exposed in my front end?
Anything your web app sends to the browser can be read by anyone, so any key in your front end is public. Some keys are designed for that, like a Supabase anon key, a Firebase config or a Stripe publishable key. Secret keys, such as a Stripe secret key, an OpenAI or Anthropic key, or a Supabase service role key, must only ever be used on your server.
Keys that are meant to be public
- Supabase anon (publishable) key, as long as row level security is on.
- Firebase web config and API key, as long as your security rules are right.
- Stripe publishable key (starts with pk_).
- Map or analytics keys that are restricted to your own domain.
Keys that must never be in the front end
- Stripe secret or restricted keys (start with sk_ or rk_).
- AI provider keys, such as OpenAI or Anthropic keys.
- The Supabase service role key, which bypasses all row level security.
- Cloud credentials, database connection strings, email or SMS provider keys.
How to check your own site
Open your live site, open the browser's developer tools, and search all loaded files (Sources, then search across files) for key prefixes such as sk_, service_role and the names of the services you use. Also check your code for environment variables exposed to the browser: in Next.js, anything named NEXT_PUBLIC_ is sent to the browser; in Vite, anything named VITE_ is.
If a secret key has leaked
- Rotate it now in the provider's dashboard, so the old key stops working.
- Check the provider's usage and billing for activity you do not recognise.
- Move the call that needed the key to your server or a server function.
- Set spending limits where the provider offers them.
Want it checked by a person?
Exposed keys are one of the things every Elitor check looks for. Start with a free check; one-off checks start at £249.
Last updated 2026-10-21.