Is your Supabase database exposed? How to check Row Level Security

Open Supabase tables are one of the most common serious issues in AI-built apps. The public key in your frontend can query your database directly, so Row Level Security (RLS) is the only thing standing between a visitor and your users' data.

1. Understand why this matters

Apps built with Lovable, Bolt, v0 or Cursor usually talk to Supabase straight from the browser using the anon key. That key ships in your JavaScript, so anyone can open DevTools, copy it and your project URL, and call the Supabase API themselves. If a table has RLS turned off, they can read every row, and often insert, change or delete rows too.

2. List tables without RLS

In the Supabase dashboard, open the SQL editor and run:

select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

Every table this returns is open to anyone with your public key. The dashboard's Security Advisor also flags these, along with other risky settings.

3. Test it from the outside

To see what a stranger sees, request a table with only the public key (swap in your project URL, table name and anon key):

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1' \ -H 'apikey: YOUR_ANON_KEY' -H 'Authorization: Bearer YOUR_ANON_KEY'

If you get rows back for a table that holds private data, it is exposed. An empty list [] usually means RLS is blocking you, which is what you want for private tables.

4. Turn on RLS and add real policies

Enable RLS on each table:

alter table todos enable row level security;

Then add policies that tie rows to the signed-in user. For a table with a user_id column:

create policy "Read own rows" on todos for select using ((select auth.uid()) = user_id); create policy "Insert own rows" on todos for insert with check ((select auth.uid()) = user_id); create policy "Update own rows" on todos for update using ((select auth.uid()) = user_id) with check ((select auth.uid()) = user_id); create policy "Delete own rows" on todos for delete using ((select auth.uid()) = user_id);

Only allow public reads on data that really is public, like published blog posts, and never allow public writes unless you mean it.

5. Look for policies that let everyone in

• Policies with using (true) or with check (true) on insert, update or delete let any visitor write. AI tools often add these to make an error go away.
• Views run with their owner's rights by default and can skip RLS. On Postgres 15 and later, create them with with (security_invoker = true), or keep them out of the public schema.
• Storage buckets marked public can be read by anyone with the file URL. Keep private uploads in private buckets with policies on storage.objects.
• The service_role key skips RLS completely. It belongs only in server code and never behind a NEXT_PUBLIC_ or VITE_ prefix.

6. Tell your AI tool the rule

Add this to your project instructions: "Every new Supabase table must enable row level security and get policies scoped to auth.uid(). Never use using (true) on insert, update or delete. Never use the service_role key in client code." Then re-check after big changes, since AI edits can quietly loosen policies.

Quick answers

General guidance. A fast automated check for the most common security mistakes in AI-built apps. Not a substitute for a full security audit. Updated 2026-10-19.

All guides · Home · Terms · Privacy