What is an exposed API key, and why does it matter?

A plain-English explanation of API keys, which ones are safe to show, which ones aren't, and what to do if yours leaked.

If you built an app that uses OpenAI, Stripe, Supabase, or almost any other service, you've used an API key. Here's what that means, and why "exposed" is a word you don't want next to it.

What an API key is

An API key is a password for one app talking to another. When your app asks OpenAI to write something, or asks Stripe to charge a card, it sends the key along to prove "this request is from my account."

Whoever has the key can act as your account. That's the whole point, and it's also the danger.

What "exposed" means

A key is exposed when someone who shouldn't have it can get it. The most common way this happens with vibe-coded apps: the key ends up inside the code that runs in your visitors' browsers.

Everything your website sends to a browser can be read by anyone. Hiding it in a long file, or giving it a boring name, doesn't help. Anyone can open their browser's developer tools and search for it. Automated bots scan public websites and code repositories for keys around the clock.

Not every key is secret

This is where it gets confusing, because some keys are meant to be public:

Stripe publishable key (starts with pk_live_ or pk_test_): safe in the browser. It can only start a checkout, not move money.
Supabase anon key or publishable key (sb_publishable_...): safe in the browser *only if* your database tables are protected with Row Level Security.
Firebase web config (the apiKey in your Firebase setup): designed to be public. Your database rules are what protect your data.

And some keys must never be in the browser:

OpenAI keys (sk-proj-... or sk-...): someone can use your account and run up your bill.
Anthropic keys (sk-ant-...): same problem.
Stripe secret keys (sk_live_...): access to your Stripe account, including your customers' payment records and refunds.
Supabase service role or secret keys (sb_secret_...): these skip every lock on your database. Whoever has one can read and delete all your data.
Any key labeled "secret", "private", or "admin".

A simple rule: if the service calls it a secret key, it belongs on a server, never in the app your visitors download.

What can happen

Surprise bills. People use leaked OpenAI or Anthropic keys to run their own projects on your account. You get the bill.
Data theft. A leaked database admin key gives a stranger the same access you have.
Account shutdown. Some services automatically disable keys they find in public places, which can break your app without warning.

How to check your app

Open your live app in Chrome.
Right-click, choose Inspect, and open the Sources tab.
Press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search every file.
Search for sk_live, sk-proj, sk-ant, sb_secret, and service_role.

If nothing comes up, that's a good sign. If something does, keep reading.

What to do if a key leaked

Make a new key in that service's dashboard.
Delete or turn off the old key. Just removing it from your code isn't enough. Someone may already have a copy.
Move the new key to the server side. Ask your builder tool: "Move this API key out of the frontend and into a server function or Edge Function secret. The browser should call my server, and my server should call the service." If your app needs a real server to hold secrets, hosts like Railway let you set private variables in a dashboard (referral link: we may earn a cut, it costs you nothing).
Check your usage and billing pages for activity you don't recognize.
Set a spending limit on paid services, so a future leak can't cost you more than you're ready to lose.

Exposed keys are one of the most common problems in apps built quickly. They're also one of the easiest to fix once you know they're there.