Free Supabase RLS checker: 3 ways to find open tables

You can check Supabase RLS for free in three ways. Open the Security Advisor in Supabase Studio. Run one SQL query that lists every public table with RLS off. Then scan your live app from outside with a free LeakCheck scan. Use all three. RLS being on does not prove your policies and grants are right. Built your app with Lovable? See how to check Supabase RLS on a Lovable app for where these checks live on Lovable's built-in backend.

1. Open the Security Advisor

Supabase ships advisors in Studio, including a Security Advisor. Its checks include 0013 rls disabled in public, 0007 policy exists rls disabled, 0008 rls enabled no policy and 0024 permissive rls policy (Database Advisors). Fix walkthroughs: Security Advisor warnings.

2. Run one SQL query

In the SQL editor, run: select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

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

The rowsecurity column of pg_tables is true when row security is on (PostgreSQL docs). Any table it returns needs attention. In Supabase's words, a table in an exposed schema without RLS "is readable and writable by any role with a grant on it" (Supabase RLS docs).

3. Check from outside with LeakCheck

Run a free read only LeakCheck scan on your live app. It looks at your app the way a stranger would. LeakCheck uses read only requests and read only Supabase probes. It never creates users or writes data. LeakCheck Free is US$0 with no card. You get one preview scan a day with no account. Sign in free for up to 5 scans every 10 minutes and the public GitHub repo check.

What a pass does not prove

• Policies do not take back grants. Supabase says adding policies does not remove the default grants to anon and authenticated. Revoke what you do not need. See 42501 permission denied and grants.
• A policy like to anon using (true) lets every signed out visitor read every row. Use it only for public data. See permissive policies.
• Views bypass RLS by default, because they are usually created by the postgres user. See views that bypass RLS.
• Supabase suggests tests that assert allow and deny for select, insert, update and delete. See test RLS in CI.
• An owner policy keeps passing a signed out user's access token until it expires. See signOut scopes and session revocation for a policy that checks the session is still live.
• A policy that trusts auth.jwt() ->> 'email' breaks when Confirm email is off, because anyone can sign up as any address. See signup user enumeration.

Found a key in your code? Read exposed Supabase key next. The full list lives in the Supabase RLS checklist.

Find open tables before someone else does. Run a free LeakCheck scan. Then let LeakCheck Pro recheck after every deploy.