Free tool · runs in your browser

RLS Policy Generator & Explainer

Row-Level Security is where most Supabase leaks come from. Generate correct policies from a pattern, or paste a policy to see in plain English exactly what it allows.

Schema

Table

Access pattern

Owner-only (per-user rows)Each user can only read and write rows they own (matched by a user-id column against auth.uid()).Public read, no writesAnyone (even anonymous) can SELECT; nobody can write through the API.Authenticated read, no writesAny signed-in user can SELECT; nobody can write through the API.Authenticated read + writeAny signed-in user can read and write every row. Use for shared, non-sensitive tables.Admin claim onlyOnly tokens whose JWT carries a truthy `is_admin` / role=admin claim can access rows.Service-role only (lock out the API)RLS with no permissive policy: the anon and authenticated roles get nothing; only the service_role key (server-side) can touch the table.

Owner column (matched against auth.uid())

Generated SQL

-- RLS for public.orders — pattern: Owner-only (per-user rows)
ALTER TABLE "public"."orders" ENABLE ROW LEVEL SECURITY;

CREATE POLICY "orders_select_own" ON "public"."orders"
  FOR SELECT TO authenticated
  USING ("user_id" = auth.uid());

CREATE POLICY "orders_insert_own" ON "public"."orders"
  FOR INSERT TO authenticated
  WITH CHECK ("user_id" = auth.uid());

CREATE POLICY "orders_update_own" ON "public"."orders"
  FOR UPDATE TO authenticated
  USING ("user_id" = auth.uid())
  WITH CHECK ("user_id" = auth.uid());

CREATE POLICY "orders_delete_own" ON "public"."orders"
  FOR DELETE TO authenticated
  USING ("user_id" = auth.uid());

Test these against real roles.

Suparbase's RLS debugger simulates any policy as anon / authenticated / a specific user, live against your project — so you know it's right before you ship.

Start free See the full product