The Supabase row level security default that leaks your entire user table

What is the Supabase RLS problem in one paragraph?

In Postgres, a newly created table has row level security disabled, and Supabase publishes every table in the public schema as a REST endpoint. Put those two facts together and a table created by a prompt, an AI agent, or a hand-run create table is readable by anyone holding your publishable anon key, which is in every browser that loads your site. It affects any app on Supabase where nobody explicitly wrote policies: Lovable, Bolt, Replit, Cursor, v0, or hand-written code. The fix is real SQL, it takes an afternoon, and it is not the same thing as hiding your key.

This is the failure that turns into a breach notification rather than a bug ticket, because the data is not stolen through a clever exploit. It is served, correctly, by your own API, to whoever asks. One developer who went looking wrote it plainly on r/lovable: "I have come across vibe-coded platforms with public Supabase endpoints exposing full user lists." Same thread, on the write side: "I could upgrade myself to premium, delete other users' data, or tamper with core records, all because PUT or PATCH endpoints were wide open."

What follows is the check you run against your own project, the mechanism explained properly so you can reason about your own schema instead of pattern-matching, the SQL that closes it, and an honest account of what correct RLS still does not protect you from.

How do I tell if my app is affected right now?

Run three checks, in this order: a curl request as an anonymous stranger, a psql inventory of every table, and the Supabase Security Advisor. The first one takes thirty seconds and answers the only question that actually matters.

export SUPABASE_URL="https://YOUR-PROJECT-REF.supabase.co"
export ANON_KEY="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."   # the key already in your bundle

curl -s -D - -o /dev/null \
  "$SUPABASE_URL/rest/v1/profiles?select=*" \
  -H "apikey: $ANON_KEY" \
  -H "Authorization: Bearer $ANON_KEY" \
  -H "Range: 0-0" \
  -H "Prefer: count=exact"

content-range: 0-0/4127     # 4,127 rows readable by an anonymous visitor. You are exposed.
content-range: */0          # zero rows visible. RLS is doing its job on this table.
HTTP/2 404 + "PGRST205"     # table not exposed through the API at all. Fine.

curl -s -w '\nHTTP %{http_code}\n' -X POST \
  "$SUPABASE_URL/rest/v1/profiles" \
  -H "apikey: $ANON_KEY" \
  -H "Authorization: Bearer $ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"full_name":"rls-probe-delete-me"}'

select
  c.relname               as table_name,
  c.relrowsecurity        as rls_enabled,
  c.relforcerowsecurity   as rls_forced,
  count(p.polname)        as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policy p on p.polrelid = c.oid
where n.nspname = 'public'
  and c.relkind = 'r'
group by c.relname, c.relrowsecurity, c.relforcerowsecurity
order by c.relrowsecurity, policy_count, c.relname;

select tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true')
order by tablename, policyname;

select grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public'
  and table_name   = 'profiles'
  and grantee in ('anon', 'authenticated');

What does row level security actually do?

Row level security makes Postgres attach a where clause of your choosing to every query against a table, invisibly, at the database level, based on who is asking. It is not a firewall, a middleware, or an API gateway. It is a filter the planner injects into the query itself, which is why it cannot be forgotten by a route handler or bypassed by a crafted request.

Three separate things have to be true for a Supabase table to be safe, and confusing them is where almost everyone goes wrong.

One: the table is exposed. Supabase runs PostgREST in front of your database. Every table in the schemas listed under Data API settings, which by default is just public, becomes a REST resource at /rest/v1/<table>. You did not opt into that per table. It is the default, and it is the product.

Two: a role has privileges. PostgREST reads the JWT you send, takes its role claim, and runs your query as that Postgres role. No JWT, or the anon key's JWT, means the anon role. A logged-in user's JWT means the authenticated role. Supabase's default privileges already grant both of those roles access to tables in public, so the SQL-level permission check passes.

Three: RLS decides which rows. This is the only layer left, and it is the one that is off by default. create table in Postgres does not enable row level security. It never has. Postgres is behaving exactly as documented; the surprise is that the table is also, simultaneously, a public API endpoint.

When you run alter table x enable row level security, the default becomes deny. With RLS enabled and zero policies, a select returns zero rows and an insert raises error 42501. Policies are purely additive permissions: each one you add is a way in, and a row is visible if any applicable policy permits it. There is no such thing as a deny policy in Postgres RLS. That matters, because adding a second, sloppier policy later silently widens access, and nothing warns you.

Two clauses do different jobs. using is the filter applied to rows that already exist, so it governs select, update and delete. with check is applied to the row as it will exist after the write, so it governs insert and the result of an update. A policy with a correct using and a missing with check on update is the classic half-fix: the user can only modify their own rows, but nothing stops them from setting user_id to somebody else on the way out and handing the row away.

Is my exposed Supabase anon key the actual problem?

No. The anon key is designed to be public and belongs in your frontend bundle, and every Supabase app on the internet ships one. Rotating it fixes nothing. The key that is genuinely catastrophic to expose is the service role key, and the two get confused constantly.

Getting this distinction right is the difference between fixing the problem and doing a week of pointless work.

Supabase is mid-migration on this naming, so expect to see either pair depending on when your project was created. Every project made before the rollout still shows anon and service_role, every project made after it defaults to sb_publishable_... and sb_secret_..., both pairs work at the same time right now, and Supabase has said it is retiring the legacy names by the end of 2026. The role, the RLS behaviour and the risk are identical either way: publishable is the new anon, secret is the new service_role.

So: public anon key plus correct RLS equals fine. That is the intended design, not a compromise. Public anon key plus no RLS equals an open database with a documented, self-describing REST API sitting in front of it, complete with filtering and ordering operators an attacker can use to page through everything you have.

The service role key is a different category of mistake entirely. It carries bypassrls, so it reads and writes every row in every table regardless of what policies exist. If it has ever been in client-side code, an NEXT_PUBLIC_ or VITE_ environment variable, a public repo, or a screenshot, treat it as compromised and rotate it. Find out today:

npm run build
grep -rE "service_role|sb_secret_|SUPABASE_SERVICE" ./dist ./build ./.next 2>/dev/null

There is more detail on secret handling and rotation order in our vibe-coding security checklist, which covers this alongside thirteen other risks.

Why do AI coding tools keep leaving RLS off?

Because the two ways to create a table in Supabase have different defaults, and AI tools use the one that defaults to off. Creating a table through the dashboard's table editor presents an Enable Row Level Security checkbox that is ticked. Running create table as SQL does not enable RLS, because plain Postgres does not.

An AI coding tool writes SQL. It runs migrations, or it pastes a create table statement into the SQL editor, or it calls a management API. None of those paths go through the dashboard checkbox. So the table exists, the app works immediately, the demo is impressive, and the security default the dashboard would have given you never applied.

The second half of the problem is that the model, asked to make a broken query work, has an obvious and wrong move available. When a feature breaks because RLS is enabled with no policy, the smallest change that makes it work again is:

alter table public.profiles enable row level security;

create policy "Enable read access for all users"
  on public.profiles
  for select
  using (true);          -- true means: every row, to every role, including anon

This is also not evenly distributed across tools, and it is worth being precise rather than lumping them together. The r/lovable developer who audited a batch of these apps reported a tool-level difference: "Open REST endpoints are happening in Lovable mostly and not in Bolt. Bolt is setting up rules by default in Supabase, whereas Lovable isn't." That is one practitioner's observation from a set of apps he looked at, not a measured study, so treat it as a reason to check your own project rather than a reason to trust or distrust a vendor. The check above costs thirty seconds and settles it for your app specifically.

The deeper pattern, and the one worth internalising: an AI agent applies whatever it does to every table in the session. A human who forgets RLS forgets it on one table. An agent that does not write policies does not write them anywhere, which is why the finding is almost never a single table. It is the schema.

What is the correct RLS policy for a user-owned table?

Enable RLS, force it, then write one narrow policy per command, scoped to the authenticated role, comparing the caller's ID from their JWT against the row's owner column. Four policies, one index, and a revoke on the columns users must not be able to set themselves.

Assume a table public.profiles with a user_id uuid column referencing auth.users(id). Run this in the SQL editor or as a migration:

alter table public.profiles enable row level security;
alter table public.profiles force  row level security;

drop policy if exists "profiles_select_own" on public.profiles;
drop policy if exists "profiles_insert_own" on public.profiles;
drop policy if exists "profiles_update_own" on public.profiles;
drop policy if exists "profiles_delete_own" on public.profiles;

create policy "profiles_select_own"
  on public.profiles for select
  to authenticated
  using ( (select auth.uid()) = user_id );

create policy "profiles_insert_own"
  on public.profiles for insert
  to authenticated
  with check ( (select auth.uid()) = user_id );

create policy "profiles_update_own"
  on public.profiles for update
  to authenticated
  using      ( (select auth.uid()) = user_id )
  with check ( (select auth.uid()) = user_id );

create policy "profiles_delete_own"
  on public.profiles for delete
  to authenticated
  using ( (select auth.uid()) = user_id );

create index if not exists profiles_user_id_idx
  on public.profiles (user_id);

begin;
select set_config(
  'request.jwt.claims',
  '{"sub":"00000000-0000-0000-0000-000000000000","role":"authenticated"}',
  true
);
set local role authenticated;

explain (analyze, buffers)
select * from public.profiles where user_id = auth.uid();

rollback;

revoke update (credits, plan, is_admin, role)
  on public.profiles
  from authenticated, anon;

How do I prove the policy actually works?

Run the same probes again and watch the answers change, then test as a real second user. A policy you have not tested from the outside is a policy you are guessing about.

Three tests, in order of how much they prove:

1. The anonymous curl from earlier. Re-run it. content-range should now read */0, and the anonymous insert should return 403 with code 42501. That proves strangers are out.
2. Two real accounts. Sign up as user A and user B in a private window, note a row ID belonging to B, then request it while holding A's access token. An empty array is correct. This proves the policy scopes by owner and not just by "logged in", which is a different bug with its own article: IDOR, where a logged-in user is treated as an authorized user.
3. The in-database simulation. The set_config plus set local role block above, run once per role, with the transaction rolled back. Fast enough to put in a test suite, and it does not require running your app at all.

Do this table by table. There is no shortcut that covers a schema you have not enumerated, which is why check 02 comes before the fix rather than after it.

What does correct RLS still not protect you from?

RLS decides which rows a role may touch. It does not decide which columns, it does not apply to anything using the service role key, and it does not know anything about your business rules. Four gaps survive a perfect set of policies.

• Views and functions that bypass it. A view executes with its owner's permissions unless it is created with security_invoker = true (Postgres 15 and later), so a view over a protected table can hand out every row. The same is true of any function declared security definer. Supabase's Security Advisor flags both, and they are the most common way a schema with correct-looking policies still leaks.
• Everything your server does with the service role key. Edge Functions, Next.js route handlers, and cron jobs holding service_role ignore RLS entirely. Every one of those needs its own ownership check written by hand. If your app fetches a record by ID in a server route using the service key, RLS will not save you.
• Storage. Supabase Storage enforces access through policies on storage.objects, which is a separate set of policies from your tables, and a bucket marked public is public. Uploaded IDs, contracts and avatars are frequently the most sensitive data in the project and the least-checked.
• Rate and volume. A policy that correctly lets each user read their own rows does not stop one user from reading their own rows ten thousand times a minute, or from enumerating every ID they have ever been shown. That is a rate-limiting and logging problem.

There is also the question RLS cannot answer at all: whether anyone already pulled the data while it was open. That is a log question, not a code question, and it is time-sensitive: Supabase's published log retention for API and database logs is 1 day on Free, 7 days on Pro, 28 days on Team and 90 days on Enterprise, at time of writing. If your probe returned rows, export your API logs before you do anything else.

When should I stop and hire an engineer?

If your app has fewer than about ten tables, no paying customers, and the probe returned zero rows, do not hire anyone. Run the inventory query, write the four policies per table, re-run the probes, and you are done in an afternoon. That is a real answer, not a hedge.

Get help when one of these is true, and each of these is a specific, bounded job rather than an open-ended engagement:

• The probe returned rows and you have real users. The code fix is the easy half. Working out what was exposed, for how long, whether anyone took it, and what your notification obligations are under GDPR or your state's breach law is the half that needs someone who has done it. It is also the half with a clock on it.
• The service role key has ever been in client code or a public repo. Rotating it means finding every consumer first, cutting over, and revoking last, without taking production down mid-rotation. Doing that in the wrong order takes the app offline.
• You cannot enumerate your own schema. If the inventory query returns tables you have never heard of, something else created them, and the policies are the second problem. The first is understanding what your database actually contains.
• Policies exist and you cannot tell whether they are right. Reading someone else's using expressions across thirty tables and knowing which ones are subtly wrong is a specific skill. An AI asked "is this secure?" will tell you it looks good.

If none of those apply, close this tab and go write the policies. Genuinely. The best outcome of this article is that you never talk to us.