Are your Supabase tables public? Check RLS in 2 minutes (Lovable, Bolt, v0)

AI app builders often create Supabase tables with Row Level Security off. Run one SQL query and one curl request to see if strangers can read your data, then fix it with a copy-paste prompt.

Why this happens

Your Supabase anon / publishable key ships in the browser by design. Row Level Security policies are the only thing between a stranger with that key and your rows. Tables created from the SQL editor or by an AI tool may not have RLS enabled.

Check 1: inside Supabase (SQL Editor)

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

Any row returned is a table anyone with your anon key can query. Also run the Security Advisor in Supabase Studio and look for rls_disabled_in_public (lint 0013) and rls_enabled_no_policy (lint 0008).

Check 2: from outside (your own project only)

curl -s "https://YOUR_PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY"

Rows back means the table is exposed. [] or a 42501 permission error means access is denied (seed a row first; an empty table always returns []). Then sign in as test user A and try to read user B's rows. That must fail.

RLS on is not the same as safe

Watch for policies like using (true), which let everyone in. Views bypass RLS by default, and RPC functions can expose data too, so review those as well.

Fix it: paste the prompt for your builder

My Lovable app uses Supabase. Enable Row Level Security on every table in the public schema, add policies so signed-in users can only select, insert, update and delete rows where user_id = auth.uid(), give signed-out visitors no access unless a table is meant to be public, and list every table and policy you changed.

My Bolt app uses Supabase. Enable Row Level Security on every table in the public schema, add policies so signed-in users can only select, insert, update and delete rows where user_id = auth.uid(), give signed-out visitors no access unless a table is meant to be public, and list every table and policy you changed.

My Base44 app uses Supabase. Enable Row Level Security on every table in the public schema, add policies so signed-in users can only select, insert, update and delete rows where user_id = auth.uid(), give signed-out visitors no access unless a table is meant to be public, and list every table and policy you changed.

My Replit app uses Supabase. Enable Row Level Security on every table in the public schema, add policies so signed-in users can only select, insert, update and delete rows where user_id = auth.uid(), give signed-out visitors no access unless a table is meant to be public, and list every table and policy you changed.

My v0 app uses Supabase. Enable Row Level Security on every table in the public schema, add policies so signed-in users can only select, insert, update and delete rows where user_id = auth.uid(), give signed-out visitors no access unless a table is meant to be public, and list every table and policy you changed.

Or the plain SQL for one table:

alter table profiles enable row level security;
create policy "own rows" on profiles for all to authenticated
  using (auth.uid() = user_id) with check (auth.uid() = user_id);

Found a service_role key in your bundle? What to do if your Supabase service_role key is exposed.

Security checklists: Lovable · Bolt · Base44 · Replit · v0