Check whether your app is giving away its keys

AI builders put keys wherever the code needs them, and browser code is public by definition. Anyone who opens your site can read it. This takes thirty seconds to check and it is the first thing I look at in any rescue.

The thirty-second check

Open your live site, press F12, open the Sources or Debugger tab, and search all files for the beginnings of key strings: sk_, service_role, AIza, xoxb, and the word secret.

Searching your repository is not enough. Keys also arrive through build-time variables that were given a public prefix by mistake.

Which keys are safe in the browser and which are not

Publishable and anonymous keys are designed to be public and are protected by access rules on the server side. Secret keys, service keys and admin tokens are not, and they let the holder do anything your app can do.

A public database key with no access rules is just as dangerous as a secret one. See the row level security page.

What to do, in this order, if a key was exposed

Rotating first and cleaning later is the right order. The old key stays valid until you revoke it, and anyone who copied it is already holding it.

For payment and email providers, also check for charges, refunds and messages you did not send.

Keeping it from coming back

The next generated feature will do the same thing again unless the boundary is explicit.

Committing a .env file to a public repository has the same effect as shipping it in the browser.