Answers / Supabase exposure

Can anyone read my Supabase data without logging in?

Matt Turley, Continuum. Updated November 5, 2026.

Why the public key is not the problem, how the rules on a table decide who can read it, and how to test your own.

The short answer

Can anyone read my Supabase data without logging in?

Yes, if a table has no row level security or has a policy that allows everyone. The public key in your app is meant to be public, so the rules on each table are the only lock. In our October scan, 31 of 177 Supabase-backed AI-built apps had at least one table answering with no login.

Why the key in your app is public on purpose

A browser app has to talk to the database, so the key it uses ships in the page code and anyone can copy it. Supabase designs for that. The protection is not hiding the key. It is row level security: rules on each table that say which rows each signed-in user may read or change.

Without those rules, or with a rule that says everyone, the public key is enough to read the table. That is the exposure to look for, not the key being visible.

What we found when we looked

We scanned 500 live apps built with Lovable, Bolt and base44 in October 2026. 177 ran on Supabase. Of those, 31 (17.5%) had at least one table that returned a row to a request with no login, and 8 had a readable table holding clearly non-public records such as users, bookings or support messages.

It is one scan on one sample at one time, with the method and denominators published on the dataset page. It shows the problem is common among quickly built apps, not that your app has it.

How to test your own app

List every table in your project and check that row level security is switched on for each one.
Open the policies on each table and read them in plain words. Anything that says the rule is simply true lets everyone in.
Make a request with only the public key and no signed-in user, and confirm each table returns nothing it should not.
Keep the service role key out of the browser entirely. It skips these rules by design and belongs on a server only.

If you find an open table

Lock it first, then investigate. Turn the rules on, then work out what was readable and for how long. If customer records were exposed, you may have duties to tell people; ask a lawyer for your region. The Supabase security review is a paid, written pass over rules, keys, storage and sign-in with a proof for each finding.

Want one concrete finding on your own app?

Paste your live app URL and your email. A short automated check runs three public-security spot-checks and sends back one specific finding and what to do about it. It is free, and it is a preview, never a clean bill of health.

Run the free is-it-safe-to-ship check. Or book a call and talk it through.

Book a call →See all services and prices →

FAQ

Straight answers

Is it a problem that my Supabase anon key is visible in my site code?

No, not by itself. The key is public by design. It becomes a problem only when a table has no row level security or a policy that lets everyone through, because then the public key is all a stranger needs.

What does row level security with no policies do?

When it is switched on and a table has no policies, ordinary requests are blocked, which is safe but often breaks your app. AI tools then sometimes add a rule that allows everyone to get the screen working again, which reopens the table.

What is the service role key and where must it not appear?

It is a powerful key that bypasses row level security. It must live only on a server you control. If it appears in browser code or a public repository, treat it as leaked and replace it.

Can I tell from outside whether someone already read my data?

Not reliably. Database logs may show requests made with the public key, but not who made them or why. Check what logging you have, and assume readable data could have been read.

Keep reading

Run the free is-it-safe-to-ship checkFree. One finding on your own app.Is my Supabase secure?A practical checklist before you launch.Supabase security reviewRow level security, keys, storage and auth, with a proof for each finding.Is my Supabase app production ready?A free check you can run on a live URL.The AI-built app exposure scanMethod, denominators and the full dataset.How to secure a vibe-coded appThe order to work in before you tell anyone it exists.My Lovable app got hackedA calm first-hours playbook.

Sources

1. AI-built app database exposure scan, October 2026, Continuum, October 2026: Used for the figures on how many scanned Lovable, Bolt and base44 apps on Supabase had a table readable with no login. Method, denominators and the full dataset are on the page.
2. Supabase: Row Level Security, Supabase: Used for what row level security is: policies on a table that decide which rows each signed-in user can read or change.
3. Supabase: API keys and the service role, Supabase: Used for the point that the service role key bypasses row level security and belongs on a server only, never in the browser.