Table grants stay wide open after policies are added

Symptom

You added policies, then a signed-out client can still insert, or a signed-in client can still delete rows the policy was meant to hide.

Root cause

Supabase's RLS guide separates grants from policies. Grants decide whether a role may run an operation at all. Policies decide which rows it applies to. On existing projects, a new table in public can start with select, insert, update, and delete already granted to anon, authenticated, and service_role. Adding policies does not revoke those grants. service_role keeps full access and bypasses RLS, so that key has to stay on the server.

In this project's migrations only, for every client-facing table:

alter table public.your_table enable row level security;
revoke all on table public.your_table from anon, authenticated;
grant select, insert, update, delete on table public.your_table to authenticated;

Grant anon nothing unless the product truly has a public read. Then write one policy per granted operation. Do not grant service_role to the browser. Do not edit other projects.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

1. In your own SQL editor, run select grantee, privilege_type, table_name from information_schema.role_table_grants where table_schema = 'public' and grantee in ('anon', 'authenticated').
2. Confirm anon has no insert, update, or delete on private tables.
3. Signed out of your own app, try the create action in the UI. It should fail.

Sources

• Supabase: Row Level Security