Your Supabase App Is Probably Leaking Data — Here's a 2-Minute Check

Short version: if your app uses Supabase and you never explicitly turned on Row Level Security and wrote a policy for every table, a stranger can very likely open their browser console and read your whole database — every user's rows, not just their own. This is the single most common critical issue we find when we rescue AI-built apps. It is also the easiest one to check yourself. This post shows you the check, explains why the gap exists, and tells you how to close it.

Why Supabase is different (and why this catches people out)

Most databases sit behind a backend server. The browser talks to your server; your server talks to the database. To reach the data, an attacker has to get through your server code first.

Supabase removes the server. That is the entire point — your frontend talks to the database *directly*, using a "public anon key" that ships inside your JavaScript. This is what makes Supabase so fast to build with, and it is completely fine on one condition: that Row Level Security (RLS) is switched on for every table, with policies that say who can read and write which rows.

RLS is the only thing standing between a user and everyone else's data. There is no server in the middle to save you.

Here is the trap: an app works perfectly in a demo whether RLS is on or off. Nothing errors. Nothing looks wrong. You log in, you see your data, you ship it. The hole is invisible until someone goes looking — and the people most likely to skip RLS are exactly the AI coding tools (Lovable, Bolt, Cursor, v0, Replit) that get you to a working demo fastest, because RLS does not help the demo work.

The 2-minute check (do this now)

You do not need to be an engineer. You need your app open in a browser.

1. Find your Supabase URL and anon key. Open your app, press F12 to open developer tools, go to the Network tab, and refresh. Look for requests going to a URL ending in `.supabase.co`. Click one — you will see your project URL (like `https://abcdefgh.supabase.co`) and, in the request headers, an `apikey`. Both are public by design; seeing them is not the problem.

2. Try to read a table without logging in. Open a new incognito window (so you are logged out). In the console, paste this, replacing the URL, key, and a table name you know exists (like `profiles`, `users`, `messages`, or `orders`):

``` fetch("https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*", { headers: { apikey: "YOUR_ANON_KEY", Authorization: "Bearer YOUR_ANON_KEY" } }).then(r => r.json()).then(console.log) ```

3. Read the result.

• •If you get back an empty array `[]` or a permission error — good. RLS is doing its job for anonymous users. (You should still confirm a *logged-in* user cannot read *other* users' rows, which is the deeper test.)
• •If you get back rows of real data — usernames, emails, messages, anything — your database is publicly readable. Anyone who views your site can do exactly what you just did.

That is the whole check. It takes longer to read this paragraph than to run it.

What this actually costs you

This is not a theoretical risk. Publicly readable tables have exposed user emails, private messages, uploaded documents, and payment details in real, shipped products. For a founder the damage is concrete: a breach notification to every user, a broken trust story on your next sales call or raise, and in regulated spaces (health, finance) a compliance problem with real penalties.

It is also not a rare mistake. Veracode's 2025 GenAI Code Security Report tested over 100 AI models across 80+ coding tasks and found 45% of AI-generated code contained security vulnerabilities, including OWASP Top 10 flaws — and this did not improve with newer or larger models. It is structural: AI tools optimize for code that runs, not code that is safe. On a Supabase app, "not safe" often means "the front door is open."

Why you can't always just ask the AI to fix it

The instinct is to paste the problem back into Cursor or Lovable and ask it to "add security." Sometimes that works for one table. Often it does not, for a specific reason: RLS is a whole-system problem, not a single-file one. Correct policies depend on how your tables relate, how your auth is set up, which columns identify a user, and what each screen is allowed to do. The same class of tool that skipped RLS in the first place usually cannot see the whole system well enough to close every gap — so you get policies that look right, pass the demo, and still leak through a path nobody checked (a join, a view, a `SECURITY DEFINER` function).

That is why a real fix is a person reading the entire schema once, not prompting until the error goes away.

How to close the gap

1. 1.Enable RLS on every table. In the Supabase dashboard, any table without RLS is a red flag. Turn it on.
2. 2.Write a policy per table that scopes rows to the authenticated user (typically comparing a `user_id` column to `auth.uid()`), and separate policies for read vs write.
3. 3.Check storage buckets too. Uploaded files have their own access rules and are a common second leak.
4. 4.Keep the `service_role` key server-side, always. Unlike the anon key, that one is a real secret and must never appear in frontend code.
5. 5.Test as a logged-in user, not just anonymously. The subtler failure is user A being able to read user B's rows — enabling RLS is not enough if the policy is wrong.

If you'd rather have someone confirm it

We rescue AI-built apps for a living, and Row Level Security is the first thing we check — because it is the one most often left open. If you ran the check above and are not sure what you are looking at, or you want every table, policy, bucket, and function checked properly, that is exactly what a Supabase security audit is: a senior engineer goes through every path to your data and tells you, in plain English, what is reachable and by whom. The first 30-minute review is free.

Either way — run the two-minute check today. It is the cheapest security work you will ever do, and the most likely to matter.