Your Supabase keys are probably in your frontend bundle. Here's how to check in 5 minutes

Here’s an uncomfortable fact: every file your browser downloads to render a website, anyone can read. That includes your app’s JavaScript. If a privileged key ever ended up in that JavaScript, it’s not hidden. It’s sitting in plain text, one view-source away from anyone who looks.

This happens more than people expect with vibe-coded apps, because it’s an easy mistake to make once and never notice. Here’s how to check your own app in about 5 minutes.

The check

This only looks at files your own browser already downloads. It doesn’t touch anyone else’s app, log in as anyone, or send any request beyond what a normal visitor’s browser sends.

Step 1: find your JavaScript files.

Open your app in a browser, right-click, and choose “View Page Source.” Look for <script src="..."> tags. Note every URL.

Step 2: fetch each one and check it.

curl -s https://your-app.example.com/assets/index.js | grep -Eo "(sk_live_|service_role|SUPABASE_SERVICE|AIza|AKIA)[A-Za-z0-9_-]+"

Repeat for every script URL you found. That command looks for the shape of a few common secret types: a live Stripe secret key (sk_live_), a Supabase service-role key, a Google API key (AIza), and an AWS access key (AKIA). Adjust the pattern for whatever your stack actually uses.

Step 3: read the result.

Nothing came back? Good sign. Move on to checking whether your anon/publishable key (which is meant to be public) actually has proper row-level security behind it: a public key with no authorization checks is its own problem, just a different one.
Something came back? That’s a real, current exposure. Treat it as urgent, not “get to it this week.”

If you found something

Rotate the key immediately, in whatever dashboard issued it (Supabase, Stripe, Google Cloud, AWS). A key you know is exposed is a key you can no longer trust, even after you fix the code.
Move the privileged call server-side. Anything that needs a service-role key, a secret API key, or similar should run on a server you control, never in code the browser downloads.
Re-run the check against the new build to confirm the new key isn’t there too.

Why this happens so often

Most of the time, it’s not carelessness. It’s a natural mistake: a call that works fine locally gets left calling a privileged endpoint directly from the frontend, because that’s the fastest way to get a feature working. The fix isn’t “be more careful.” It’s moving that one call behind a small server endpoint, once, and then it’s fixed for good.

Or, we do it for you

This is check #1 of the 15-point audit we run for free. See the full checklist. If you’d rather have someone else check all 15 and fix what they find, get a free production audit, or see our Secrets & Access Lockdown if you already know you need it fixed fast.

FAQ

Is this safe to run on someone else’s app?

Only run this against apps you own. It’s a passive, read-only check of files any visitor’s browser already downloads, but running it against a third party without permission is out of scope for what we’d recommend, and for what we do ourselves.

What if I don’t find anything with this exact command?

The command above checks a few common patterns. Your stack might use a different key format. Adjust the pattern, or just read through the fetched files by eye for anything that looks like a long, random string tied to a service you use.

Does this mean my app is fully secure?

No. This is one check out of 15. See the full production checklist for the rest.