Início / RLS / Mudança de grants de 30/10 · Read in English

Supabase RLS · Mudança na plataforma

Mudança de grants do Supabase em 30/10: o que quebra e a correção que vaza

01 O que muda em 30 de outubro

Até agora, toda tabela criada em public recebia automaticamente privilégios completos (select / insert / update / delete e outros) pra anon, authenticated e service_role, via default privileges. Em 30 de outubro de 2026 o Supabase desliga isso em todos os projetos existentes (projetos novos já vêm assim desde um rollout gradual que começou em 30 de maio). A partir daí:

Conexões diretas ao Postgres (psql, ORM, servidor com connection string) não são afetadas. Fonte: anúncio oficial do Supabase (em inglês).

02 Como é o "quebrou"

A primeira tabela nova depois da virada devolve isso pela API, em vez das linhas:

resposta (exemplo do anúncio do Supabase)

{
  "code": "42501",
  "message": "permission denied for table invoices",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.invoices TO anon;"
}

O Postgres recusa a query antes mesmo de o RLS rodar. É o novo padrão funcionando como deveria, não um bug nas suas policies.

03 A correção que vaza

O jeito mais rápido de sumir com o erro é o grant em massa da seção de rollback do anúncio:

não cole isso como correção

grant select, insert, update, delete on all tables in schema public
  to anon, authenticated, service_role;

Funciona, e também libera todas as tabelas de public, inclusive as que você nunca quis expor. Qualquer uma delas com RLS desligado passa a poder ser lida e escrita por quem tiver sua anon key, que vai junto no seu frontend. O novo padrão era a chance de parar de expor tabela sem querer; o grant em massa devolve o problema. Peça pra uma ferramenta de IA "corrigir o erro de permissão" e essa linha é uma resposta bem provável.

Dê grant por tabela, e só o que cada role precisa.

04 O padrão de migration que funciona

Trate grant, RLS e policies como uma coisa só, na mesma migration, pra tabela nunca existir pela metade:

migration.sql

create table public.invoices (
  id         bigint generated always as identity primary key,
  user_id    uuid not null references auth.users(id),
  amount     numeric not null
);

alter table public.invoices enable row level security;

create policy "owner reads" on public.invoices for select to authenticated
  using (user_id = (select auth.uid()));

-- só o role e as operações que o app realmente usa
grant select on public.invoices to authenticated;

Sem grant pra anon aqui, porque visitante deslogado não lê fatura. Se a tabela usa serial / bigserial em vez de identity e a API insere nela, a sequence precisa do próprio grant: grant usage, select on sequence public.invoices_id_seq to authenticated;

05 Veja o que os roles da API alcançam hoje

Rode isso no SQL editor. Lista toda tabela e view de public, se anon ou authenticated conseguem ler, e se o RLS está ligado:

check.sql

select c.relname,
       has_any_column_privilege('anon', c.oid, 'select')          as anon_can_read,
       has_any_column_privilege('authenticated', c.oid, 'select') as auth_can_read,
       c.relrowsecurity                                              as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p', 'v', 'm')
order by 1;

Tabela com anon_can_read = true e rls_on = false pode ser lida por qualquer um com a sua anon key. Dois detalhes deixam essa consulta mais rigorosa que a versão comum baseada em information_schema.table_privileges:

06 Pra não voltar a acontecer

O novo padrão só te protege enquanto toda migration estiver certa. Dois checks grátis ajudam:

FAQ