VibeSecurely
All tools

Supabase

Supabase RLS Policy Generator

Generate copy-paste Supabase Row-Level Security SQL.

Runs locally - nothing uploaded

Who can read rows?

Write operations (owner-scoped)

Generated SQL
-- Enable RLS. Until a policy allows it, every row is denied to the public API.
alter table public.todos enable row level security;

create policy "Select own todos"
  on public.todos
  for select
  to authenticated
  using ( auth.uid() = user_id );

create policy "Insert own todos"
  on public.todos
  for insert
  to authenticated
  with check ( auth.uid() = user_id );

create policy "Update own todos"
  on public.todos
  for update
  to authenticated
  using ( auth.uid() = user_id )
  with check ( auth.uid() = user_id );

create policy "Delete own todos"
  on public.todos
  for delete
  to authenticated
  using ( auth.uid() = user_id );

Policies anchor to auth.uid() so a row is only reachable by its owner. Review against your schema and test by impersonating users before you rely on it.

About this tool

Generate correct Supabase Row-Level Security policies in seconds. Pick your table, owner column, and operations, and get copy-paste SQL that locks each row to its owner with auth.uid().

Related reading

Frequently asked questions

What does this generate?
It produces the SQL to enable Row-Level Security on your table plus create policy statements for the operations you choose (select, insert, update, delete), each anchored to auth.uid() so a row is only accessible to the user who owns it.
Is the generated SQL safe to run in production?
It is a correct starting point for owner-scoped access, but you should review it against your schema, adapt the owner column to match your table, and test it by impersonating different users in the Supabase SQL editor before relying on it.
Why anchor policies to auth.uid()?
Because auth.uid() is the identity Supabase verifies from the user's session, an attacker cannot forge it. Policies that instead trust a user ID sent from the browser can be bypassed by simply changing that value, so always derive identity from auth.uid().