Strangers can see your users? The Supabase RLS guide

What happens when RLS is off

Supabase gives your frontend a key that’s meant to be public: the publishable key (sb_publishable_…), or the legacy anon key. It goes into your JavaScript, every visitor gets a copy, and that’s fine. It’s the ticket everyone gets at the door of the club.

What decides where that ticket gets you is Row Level Security (RLS). Supabase exposes the tables in your public schema through its Data API. When RLS is off on a table, the API doesn’t check who’s asking, so anyone holding the public key can read the whole table. Supabase’s own security advisor puts it bluntly: anyone with your project URL can read, edit, and delete all data in that table.

Here’s all it takes. Your project URL and public key are already in your site’s JavaScript:

# What a stranger can do when RLS is off on your users table
curl 'https://YOUR-PROJECT.supabase.co/rest/v1/users?select=*' \
  -H 'apikey: YOUR_PUBLISHABLE_KEY'

# → every row: ids, emails, names…

THE BUILDER’S TAKEAWAYThe public key is not the bug. A table without RLS is the bug. The key is the ticket; RLS is the bouncer.

• Supabase: understanding API keys
• Supabase: Performance and Security Advisors
• Supabase: Row Level Security

Find every table without RLS

Two ways to check, and it takes under a minute. In the dashboard, open Advisors → Security Advisor and look for RLS Disabled in Public (lint 0013_rls_disabled_in_public). Or run this in the SQL editor:

-- Tables in the public schema with Row Level Security turned OFF
select schemaname, tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false
order by tablename;

While you’re in Advisors, also check Security Definer View (0010) and Exposed Auth Users (0002). Both are ways data slips past RLS through a view.

THE BUILDER’S TAKEAWAYMake “zero tables with RLS off” a launch requirement, the same as “the build passes”.

• Supabase: Performance and Security Advisors
• PostgreSQL: row security policies

Turn on Row Level Security

Enabling RLS is one line per table:

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

Or switch it on for every table in public at once:

do $$
declare t record;
begin
  for t in
    select tablename from pg_tables
    where schemaname = 'public' and rowsecurity = false
  loop
    execute format('alter table public.%I enable row level security', t.tablename);
  end loop;
end $$;

THE BUILDER’S TAKEAWAYRLS on with no policies is “deny everything”, the safest starting point. You open access one policy at a time.

• Supabase: Row Level Security
• PostgreSQL: row security policies

Write policies: everyone sees only their own rows

A policy is a rule Postgres adds to every query. using (…) decides which existing rows are visible or editable. with check (…) decides which new or changed rows are allowed. The classic rule for personal data is “a row belongs to the user whose id is on it”:

create table public.profiles (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null default auth.uid() references auth.users on delete cascade,
  display_name text
);
alter table public.profiles enable row level security;

create policy "Users can view their own profile"
on public.profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Users can create their own profile"
on public.profiles for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users can update their own profile"
on public.profiles for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

create policy "Users can delete their own profile"
on public.profiles for delete
to authenticated
using ( (select auth.uid()) = user_id );

-- policies filter on user_id, so index it
create index profiles_user_id_idx on public.profiles using btree (user_id);

Why every detail is there

• to authenticated skips the policy entirely for logged-out visitors (anon), which is faster and clearer.
• (select auth.uid()) instead of auth.uid(): wrapping it lets Postgres compute your user id once per query instead of once per row. Supabase recommends it for performance.
• with check on insert and update: without it, a user could write a row with someone else’s user_id.
• An index on user_id: the policy filters on that column for every query, so an unindexed column turns reads into full table scans.

Public content is a policy too

Not everything is private. A blog, a product catalogue or a public profile page can be readable by everyone, but only the parts you choose:

create policy "Anyone can read published posts"
on public.posts for select
to anon, authenticated
using ( published = true );

-- RLS is "on", but this lets everyone do everything
create policy "allow all"
on public.profiles for all
using ( true );

-- Scoped to the owner, per action, per role
create policy "Users can view their own profile"
on public.profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

THE BUILDER’S TAKEAWAYOne policy per action, scoped to the owner, with the role named. using (true) is a velvet rope with no bouncer.

• Supabase: Row Level Security
• PostgreSQL: CREATE POLICY

Test it like a stranger would

Don’t trust the dashboard, which uses elevated access. Test with the same public key your site ships, and with no session:

# Logged-out stranger: should return [] (or a permission error), never real rows
curl 'https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*' \
  -H 'apikey: YOUR_PUBLISHABLE_KEY'

Then check a signed-in user only sees their own rows. In the SQL editor you can impersonate one inside a transaction that rolls back:

begin;
  set local role authenticated;
  set local request.jwt.claims to '{"sub": "PASTE-A-USER-UUID", "role": "authenticated"}';

  select * from public.profiles;   -- only that user's row
  select count(*) from public.profiles where user_id <> 'PASTE-A-USER-UUID';  -- 0
rollback;

import { createClient } from '@supabase/supabase-js'

// Same URL + publishable key the browser uses, no session
const stranger = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_PUBLISHABLE_KEY!)

const { data } = await stranger.from('profiles').select('*')
if (data && data.length > 0) throw new Error('RLS leak: a stranger can read profiles')

THE BUILDER’S TAKEAWAYIf a logged-out request with your public key returns real rows, you have a leak. Test it the way an attacker would.

• Supabase: Row Level Security

Mistakes that quietly bypass RLS

create view public.my_orders
with (security_invoker = true)
as select id, total, created_at from public.orders;

And renaming the table doesn’t help

In the episode, Aster tries to rename his table users_definitely_not_emails_v2_final. Grok’s verdict: “Bro thinks security through obscurity is a personality.” Your frontend calls supabase.from('…') with the real table name, so the name is in your JavaScript too. A confusing name is not a bouncer.

THE BUILDER’S TAKEAWAYRLS protects tables. Keys, views and metadata can route around it, so check those too.

• Supabase: Row Level Security
• Supabase: understanding API keys
• Supabase: Performance and Security Advisors