A Supabase RLS checklist for vibe-coded apps

01

See which tables are open

Paste this into the SQL Editor. It lists every table in the public schema, whether RLS is on, and what a signed-out visitor holding your public key is allowed to attempt.

-- Every public table: is RLS on, and what may a signed-out visitor try?
select c.relname as table_name,
       c.relrowsecurity as rls_enabled,
       has_table_privilege('anon', c.oid, 'select') as anon_can_read,
       has_table_privilege('anon', c.oid, 'insert,update,delete') as anon_can_write
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind in ('r', 'p')
order by c.relrowsecurity, c.relname;

Any row where rls_enabled is false is the first thing to fix. A row where anon_can_write is true deserves a second look even if RLS is on, because a loose policy plus a write grant is still a way in. If you’d rather click than type, the Security Advisor in the Supabase dashboard flags tables in the public schema that have RLS disabled.

02

Turn RLS on for every table

alter table public.notes enable row level security;

Do it for every table in public, not only the ones that feel sensitive. According to Supabase’s API security guide, tables created in the dashboard’s Table Editor have RLS on by default, but tables created in the SQL Editor or by another tool need it turned on by hand. If an AI wrote your migrations, check.

Once RLS is on and a table has no policies yet, the public key can’t read anything from it. That is the safe way to fail. If part of your app goes blank, nothing is broken in a scary way. The next two steps give back exactly the access you want, and no more.

03

Trim the grants

Postgres checks two things before a request touches a table. Grants decide whether a role may run an operation on the table at all. Policies decide which rows that operation applies to. The Supabase docs point out that on many projects a new table in public starts out granting select, insert, update, and delete to both anon and authenticated, and that adding policies does not take those grants back.

-- Start from nothing for the two client roles...
revoke all on table public.notes from anon, authenticated;

-- ...then give back only what the app needs.
-- Here: signed-in users work with notes, signed-out visitors get nothing.
grant select, insert, update, delete on table public.notes to authenticated;

Only revoke from anon if signed-out visitors truly don’t need the table. If your landing page reads from it, grant select back to anon as well and let a policy decide which rows they see, as in step 5.

04

Write one policy per operation, tied to auth.uid()

For data that belongs to a user, the rule is almost always the same: you may touch a row if its owner column matches the ID of the person asking. auth.uid() returns that ID. Write a separate policy for each operation, so you can see at a glance what each one allows.

-- Assumes public.notes has a user_id uuid column that holds the owner's auth.users id.
create policy "Owners can read their notes"
on public.notes for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Owners can add their notes"
on public.notes for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Owners can edit their notes"
on public.notes for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

create policy "Owners can delete their notes"
on public.notes for delete
to authenticated
using ( (select auth.uid()) = user_id );

-- Policies filter on user_id for every query, so index it.
create index if not exists notes_user_id_idx on public.notes (user_id);

A few details here that are easy to get wrong:

• using decides which existing rows a user can see, change, or delete. with check decides what a new or changed row is allowed to look like. The update policy needs both, otherwise a user could edit their own row and set user_id to someone else’s.
• to authenticated keeps the policy away from signed-out requests altogether. For a signed-out request auth.uid() is null, so the comparison would fail anyway, but saying it out loud makes your intent obvious to the next person (or AI) who edits the table.
• Wrapping the call as (select auth.uid()) is the form Supabase recommends. Postgres works it out once per query instead of once per row, which matters as tables grow. So does the index on user_id.

05

Be deliberate about what is public

Some data really is public, like published blog posts or a product catalogue. That is fine. Say so explicitly, and keep the rule as narrow as the data.

-- A blog where anyone may read published posts, and nobody writes from the browser.
alter table public.posts enable row level security;
revoke all on table public.posts from anon, authenticated;
grant select on table public.posts to anon, authenticated;

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

A policy that says using (true) for anon lets every stranger read every row. Use it only for data you would be happy to see on a billboard. Then list every policy you have and read them slowly:

-- Every policy in public. Read the qual and with_check columns slowly.
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

One thing that catches people out: RLS works on whole rows, not columns. If one table mixes things that are fine to show (a display name) with things that are not (an email address, a payment status), the private columns travel with every row a policy lets through. Palmer’s write-up recommends splitting sensitive data into its own table with its own stricter policy. That is usually the cleanest fix.

06

Don’t base rules on user_metadata

It is tempting to store a role like admin in a user’s metadata and check it in a policy. The Supabase docs warn against using raw_user_meta_data for that, because a signed-in user can update it themselves. Authorization data belongs in raw_app_meta_data, which users can’t change, or in a table of your own that users can’t write to.

07

Check your views

Views are easy to forget. Supabase’s docs explain that a view usually runs with its creator’s rights, so by default it ignores the RLS on the tables underneath and can hand out every row your policies were meant to hold back. On Postgres 15 and later you can make a view respect those policies:

-- Postgres 15 and later: make the view respect the RLS of the tables it reads.
alter view public.my_view set (security_invoker = true);

On older Postgres versions, revoke access to the view from anon and authenticated, or move it to a schema the API doesn’t expose.

08

Check your storage buckets

Files have the same problem as tables, with a twist. Supabase’s bucket docs say a public bucket skips access control for reading: anyone with a file’s URL can download it. That is right for avatars and product photos. It is wrong for invoices, ID scans, or anything a user would be upset to see on someone else’s screen. Buckets are private by default, so look at which ones were switched to public:

select id, name, public from storage.buckets;

For private buckets, access is decided by RLS policies on storage.objects. A common pattern, adapted from Supabase’s storage access control guide, keeps each user inside a folder named after their user ID:

-- Private bucket "documents", one folder per user: documents/<user id>/file.pdf
create policy "Users upload into their own folder"
on storage.objects for insert
to authenticated
with check (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);

create policy "Users read their own folder"
on storage.objects for select
to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);

This assumes your app uploads files to paths like <user id>/file.pdf. If it doesn’t, change the upload path first, then add the policies.

09

Keep the service_role key off the client

There is a trap worth naming here. You turn on RLS, part of the app stops loading, and the quickest-looking fix is to swap in the service_role key because then everything loads again. It loads because that key ignores every rule you just wrote. If it ends up in the browser, your whole database is open again, this time with no rules at all.

• Keep it in server code only: an API route, an Edge Function, a background job. Any environment variable with a NEXT_PUBLIC_ or VITE_ prefix gets bundled into the browser, so the secret key must never have one. Supabase’s API keys guide says the same.
• Supabase is moving projects from the legacy anon and service_role keys to publishable and secret keys. The new secret keys are refused when a request comes from a browser, which helps, but the docs are clear that someone who copies a leaked key can still use it from other tools.
• If you think the key has shipped, fix the code first, then rotate the key. The API keys guide has the steps.