Supabase RLS policy checker

How to get your SQL

If you wrote your policies in migration files, paste those. If your AI tool created them, or you're not sure, export what's actually in your database:

1. In your Supabase dashboard, open the SQL Editor.
2. Paste the query below and click Run. It only reads your settings; it doesn't change anything.
3. Copy the line column from the results and paste it into the checker.

select line from (
  select 1 as o, format('create table %I.%I ();', schemaname, tablename) as line
    from pg_tables where schemaname = 'public'
  union all
  select 2, format('alter table %I.%I enable row level security;', schemaname, tablename)
    from pg_tables where schemaname = 'public' and rowsecurity
  union all
  select 3, format('create policy %I on %I.%I as %s for %s to %s%s%s;',
      policyname, schemaname, tablename, permissive, cmd,
      array_to_string(roles, ', '),
      coalesce(' using (' || qual || ')', ''),
      coalesce(' with check (' || with_check || ')', ''))
    from pg_policies where schemaname in ('public', 'storage')
) t order by o;

It lists every table in your public schema, which of them have RLS enabled, and every policy on your tables and storage, written as SQL the checker can read.

What it checks

• Tables without RLS, which anyone with your project URL can read and change.
• USING (true) and WITH CHECK (true) on tables that hold user data.
• INSERT policies with no WITH CHECK, so nothing limits what rows a user can create.
• Policies that only check someone is signed in (auth.uid() is not null), which give every user everyone's rows.
• Write access for anon or public, including policies with no TO clause, which default to every role.
• Policies that trust user metadata, which users can edit themselves.
• FOR ALL policies, which Supabase recommends splitting into separate select, insert, update and delete policies.
• Storage policies that don't tie files to a user.
• Views without security_invoker and security definer functions, which can skip RLS.
• Performance: auth.uid() not wrapped in (select …).

What it can't tell you

The checker reads SQL for common mistakes. It doesn't connect to your project, see your data, or understand what your app is supposed to allow, so a clean result is a good start, not a security sign-off.

Always confirm by testing: try reading your private tables as a logged-out stranger, and try reading one user's rows as another. The Supabase RLS guide walks through both tests with copy-paste commands.