API keys and secrets, explained for founders

What is an API key?

An API key is a string of characters that acts as a password between two pieces of software. When your app asks another service to do something, like charge a card, send an email, or answer a prompt, it sends the key so the service knows the request is really from you and bills the right account.

There are two broad kinds, and the difference matters:

• Public / publishable keys are meant to be visible in the browser. They can only do safe, limited things. Supabase's anon key and Stripe's publishable key are examples.
• Secret keys are meant to stay on your server, never in the browser. They can do powerful things: move money, read all data, act as an admin.

Related terms: environment variable (where keys are stored) and Supabase.

Why is a secret key in your browser bundle dangerous?

A secret key in your browser bundle is dangerous because everything the browser downloads is public. Your app's front-end code is shipped to every visitor, and anyone can open their browser tools and read it. If a secret key is baked into that code, it is not hidden, it is published.

Once someone has your secret key, they can do whatever that key allows, using your account and your money. A leaked payment key can be used to trigger charges or refunds. A leaked AI provider key can run up a large bill on your card. A leaked database service key can read or delete every record, bypassing row-level security entirely.

This happens by accident all the time in AI-built apps, usually when a key was given a browser-exposed name to make a client-side error go away. See environment variables for how that naming trap works.

What do I do if a key leaks?

If a secret key has been exposed, rotate it, which means generate a new key in the service's dashboard and delete the old one, so the leaked value stops working. Deleting the key from your code is not enough on its own, because copies may already exist in old builds, in your version history, or in someone's notes.

The order to work in:

1. Generate a replacement key in the provider's dashboard.
2. Update your app to use the new key, stored as a server-only environment variable.
3. Revoke (delete) the old key so the leaked value is dead.
4. Check the provider's usage logs for any activity you don't recognize.

Explain My Build reads your code and flags secret-looking keys that appear to be exposed to the browser, then puts "rotate this key" on your fix-list. It reads code, so it flags likely exposure; it does not test whether a key has actually been abused.