Is a secret key or admin page visible on my live app?

Your live app sends code to every visitor's browser. If a secret key or an unprotected admin page ends up in that code, anyone who looks can use it: to read your customers' data, change it, or run up charges on your accounts. You won't see it happen.

It's not rare. Of 28 live apps people pasted into our free test (27 September to 3 October 2026), 5 let anyone read data that should be private.

Which keys are fine in the browser, and which never are

• Fine in the browser: publishable keys. Supabase calls its publishable (anon) key "Safe to expose online", but only because row-level security protects your tables: "enable it on every table before you deploy". Stripe's publishable key (pk_live_…) is also made for the browser.
• Never in the browser: secret keys. Supabase: a secret key "bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control." Stripe: "Only publishable keys are safe to expose outside your application's backend." That covers sk_live_… and restricted rk_live_… keys. The same goes for any key an AI or email provider calls "secret".

Check your live app in 5 minutes

1. Open your live site in Chrome on a computer and press F12.
2. Press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search all of the site's files, and search one at a time for: sk_live, rk_live, service_role, secret, private_key.
3. Any hit on a secret key is a problem. A pk_live or Supabase publishable or anon key alone is normal.
4. Now open a private window, signed out, and try your admin addresses directly, for example /admin, /dashboard, /settings. If any of them shows real data or controls without a sign-in, anyone can do the same.
5. While signed out, also try a page that should belong to a user, for example a profile or an order link. It should ask you to sign in.

Fix it

1. Move the secret key out of the front end. It belongs in a server-side function, where your builder keeps secrets (an edge or backend function with an environment secret), never in the page code.
2. Replace the leaked key. Once a secret key has been public, treat it as compromised. In Supabase, create a new secret key under Settings → API Keys, switch your app to it, then delete the old one. In Stripe, rotate the key from the API keys page. Do this even after you move the key, because copies may already exist.
3. Protect admin pages on the server, not just by hiding the link. The page or its data request must check that the signed-in person is an admin.
4. Turn on row-level security for every table with user data. There's more in Users can see other users' data.

Or paste this into your builder:

On my LIVE site, a secret key or an admin page may be exposed to visitors. Move every secret key (Stripe sk_ or rk_, Supabase secret or service_role, any provider secret) out of front-end code into a server-side function that reads it from an environment secret. Make every admin page and admin data request check on the server that the signed-in user is an admin. Make sure row-level security is on for every table with user data. Then list each change and tell me which keys I must rotate.

Then publish, search the live site's files again, and confirm nothing secret shows up.

Check it the way a stranger would

Paste your app's link at vibe-fixer.com. An AI agent goes through your live app like a new visitor, tells you what it could reach that it shouldn't, and gives you the exact fix for one problem to paste into your builder, free. Then it re-tests the live app to prove it worked. No account needed.

Related: Users can see other users' data · Test your live app like a real customer