Free toolSupabase RLS policy checker

What the checker looks for

Policies of true

Insert, update or delete policies with using (true) or with check (true), which apply to other users’ rows too. The Security Advisor calls this “RLS Policy Always True”.

Sign-in-only checks

Policies that only test auth.uid() is not null or auth.role() = 'authenticated', so every signed-up user reaches every row.

user_metadata in policies

Roles or tenants read from user_metadata, which users can edit themselves with supabase.auth.updateUser().

Policies with RLS off

Policies on a table where row-level security was never enabled, or was disabled later, so the policies do nothing.

Open with check

Updates scoped by using but with check (true), so a user can hand a row to someone else or set role or plan columns.

Storage buckets

Policies on storage.objects that only check the bucket, so anyone they cover can list and download every file, or upload, overwrite and delete files in other users’ folders.

Security definer functions

Functions that bypass RLS, are still executable by anon or every user through supabase.rpc(), or have no fixed search_path.

Overlapping and slow policies

Several permissive policies for the same role and action (the loosest wins), auth.uid() evaluated per row, and policies with no TO clause.

Questions

Is my SQL sent anywhere?

No. The check runs in your browser with JavaScript, and the SQL never leaves the page. Only an anonymous count of findings is recorded for usage statistics.

How is this different from the Security Advisor in the Supabase dashboard?

The Security Advisor checks your live database, which is the better source once a migration is applied. This tool reads SQL before it runs, so you can check a migration your AI builder wrote, or a pull request, before it reaches the project. Several of its checks follow the Advisor’s own lints.

If the checker finds nothing, are my policies secure?

Not necessarily. It reads the SQL text for common risky patterns. It can’t see policies changed in the dashboard or in earlier migrations you didn’t paste, what your functions do, or whether a policy matches what your app intends. Testing each policy as a second user is how you confirm it.

Why is auth.uid() is not null not enough?

Anyone can sign up for your app unless you close sign-ups, and your anon key ships inside it. A policy that only checks for a signed-in user lets every user read or change every other user’s rows through supabase-js.

Why wrap auth.uid() in a select?

Written as (select auth.uid()), Postgres can evaluate it once per query instead of once per row. The result is the same, and on large tables the query can be much faster. Supabase’s RLS guide recommends it.

What should I paste?

The files in supabase/migrations, in order, or the output of supabase db dump. Include the create table and alter table statements, so the checker can tell whether RLS is enabled on the tables your policies cover.

Sources: Supabase row-level security guide, Supabase database linter and the Postgres CREATE POLICY reference. Using Firebase instead? Try the Firebase Security Rules checker.

Link to this checker

Writing about Supabase security, a starter template’s README or a forum answer about RLS? You’re welcome to link here. The checker is free, needs no sign-up, and never uploads the SQL.