Paste your Supabase schema. See which tables strangers can read.

Option 1: Supabase CLI (best)

Dumps every table, policy, and function in your public schema, exactly what this tool wants.

supabase db dump --schema public

Option 2: Supabase dashboard

Open your project, go to SQL Editor, run the query below, then copy the whole result table (header row included) and paste it here.

select * from pg_policies;

RLS never enabled

Tables in your public schema with Row Level Security off. Anyone with your anon key can read and write them.

RLS on, zero policies

Fails closed, but usually means client code is leaning on the service role key.

World-readable sensitive tables

USING (true) on SELECT for tables named users, profiles, orders, payments, messages, and similar.

Wide-open writes

INSERT, UPDATE, or DELETE policies with USING (true), WITH CHECK (true), or no WITH CHECK at all.

Anonymous write grants

Write policies granted TO anon or TO public with no ownership condition.

Nullable auth.uid() compares

Policies comparing auth.uid() to a nullable column without an IS NOT NULL guard.

SECURITY DEFINER hygiene

Definer functions without a pinned search_path. Informational.

Open Storage policies

storage.objects policies that let strangers list, read, upload, or delete files.

Is it safe to paste my database schema here?

Yes. The analyzer runs entirely in your browser as JavaScript. Your SQL is never sent to a server, never logged, and never stored. If you click "create shareable link", only the score, check types, and severity counts are saved, never the SQL, table names, or policy names. You can verify this in your browser dev tools: no network request fires when you run the check.

How do I export my Supabase schema?

Run "supabase db dump --schema public" with the Supabase CLI, or in the dashboard open SQL Editor and run "select * from pg_policies;" and paste the output. Both formats work here.

What does USING (true) mean in a policy?

USING (true) means the policy matches every row for everyone the policy applies to. On a SELECT policy it makes the whole table world-readable to anyone holding your anon key, which ships inside your frontend bundle. That is fine for genuinely public data and a leak for anything per-user.

Do I need RLS on every table?

On every table in the public schema, yes, because Supabase exposes the public schema through an auto-generated API keyed by your anon key. A table without RLS is readable and writable by anyone who opens your site and copies the key out of the bundle.

My table has RLS enabled but zero policies. Is that bad?

It fails closed: nobody can read it through the API. That is safe but usually a smell. If your app still reads the table, it is probably using the service role key from client code, which bypasses RLS entirely and is an emergency of its own.

Does this replace a security audit?

No. It catches the most common RLS mistakes in what you paste, heuristically. It cannot see your auth flows, edge functions, API routes, or business logic. Treat it as triage: it tells you whether the door is open, not everything that could walk through it.