"Infinite recursion detected in policy" sem desligar o RLS

Você ligou o Row Level Security, escreveu uma regra para que admins vejam todos os perfis e cada um veja só o seu, e agora nenhuma tela do seu app carrega. Toda leitura volta com a mesma linha:

infinite recursion detected in policy for relation "profiles"

A maioria das respostas que você vai achar diz a mesma coisa, e é a coisa errada: desligue o Row Level Security nessa tabela até resolver. O erro realmente para. O que faz ele parar é que a tabela agora pode ser lida por qualquer um que visite o seu site.

O que significa "infinite recursion detected in policy for relation"

Uma regra numa tabela precisou ler essa mesma tabela antes de conseguir responder.

Imagine um porteiro que confere cada visitante numa lista de convidados, e a lista fica dentro da sala que ele está guardando. Para ler a lista ele tem que entrar. Para entrar ele tem que conferir a lista. Não existe primeiro passo, então ele fica no corredor e ninguém vai a lugar nenhum.

Foi isso que aconteceu com o seu banco. Pediram algumas linhas de profiles, ele foi até a regra de profiles para descobrir quais você podia ver, e a regra mandou ele olhar em profiles. O Postgres percebe que está andando em círculo, desiste e levanta o erro com o código 42P17 junto. A Supabase repassa isso intacto para o seu app, e é por isso que parece linguagem de máquina.

A consulta falha para todo mundo a quem a regra se aplica, então isso costuma chegar como um app inteiro ficando em branco de uma vez, e não como uma tela quebrada.

O círculo, desenhado

A regra que provoca isso é a que quase todo mundo escreve primeiro, porque ela diz exatamente o que você quer dizer:

-- Rejeitar: isto lê profiles para decidir quem pode ler profiles.
create policy "admins read every profile" on profiles for select
to authenticated
using (
  exists (
    select 1 from profiles
    where id = (select auth.uid()) and role = 'admin'
  )
);

O exists (select 1 from profiles …) é o problema inteiro. Ler profiles significa aplicar a regra de profiles, que roda exists (select 1 from profiles …) de novo.

O próprio guia de Row Level Security da Supabase nomeia a versão com duas tabelas: policies em duas tabelas que leem uma a outra nunca se resolvem, e a consulta falha para cada papel a que as policies se aplicam. Uma tabela lendo a si mesma é a mesma forma sem o desvio.

Por que isso sempre acontece na tabela profiles?

Porque é em profiles que fica quem é essa pessoa.

Qualquer regra que trate um tipo de pessoa diferente de outro precisa descobrir de que tipo é quem está chamando, e esse dado mora numa coluna de alguma tabela. Seja qual for o nome dessa tabela, a regra que protege ela acaba lendo ela. Num app feito com Lovable, Bolt, v0 ou Replit costuma ser profiles, porque é ali que vai parar a linha de cada pessoa logada. Uma regra sobre times, organizações ou documentos compartilhados produz o mesmo círculo na tabela que guarda a participação.

Então a recursão sai de escrever a regra óbvia sobre a única tabela que precisa responder uma pergunta sobre si mesma.

O conserto: um auxiliar que lê a tabela fora das regras

Mude a pergunta para uma função pequena que roda como dona do banco, para que ler profiles e responder não passe pela regra de profiles.

create schema if not exists private;

create function private.is_admin()
returns boolean
language sql
security definer      -- roda como o papel que a criou
set search_path = ''  -- assim todo nome lá dentro precisa vir por extenso
stable
as $$
  select exists (
    select 1 from public.profiles
    where id = (select auth.uid()) and role = 'admin'
  );
$$;

revoke execute on function private.is_admin() from public;
grant usage on schema private to authenticated;
grant execute on function private.is_admin() to authenticated;

-- A regra agora pergunta para a função em vez da tabela.
create policy "admins read every profile" on profiles for select
to authenticated
using ( (select private.is_admin()) );

Agora o porteiro tem a lista de convidados numa mesa do corredor. Ele lê sem abrir a porta, e a porta continua fechada para todos que não estão nela.

Quatro linhas ali fazem um trabalho específico, e três delas são a diferença entre um conserto e um buraco novo:

• security definer é o que quebra o círculo. O guia da Supabase define isso como uma função que roda sob o mesmo papel que criou a função, e na Supabase esse papel é o postgres, que pode ler por cima das regras.
• set search_path = '' cabe em cada uma delas. A orientação da Supabase é colocar isso em toda função security definer e escrever os nomes de tabela por extenso, porque sem um search_path fixado quem chama pode apontar um nome não qualificado para um objeto próprio e rodá-lo com os privilégios do dono da função. É por isso que a função escreve public.profiles por extenso.
• O schema private importa pelo mesmo motivo. O guia da Supabase avisa que uma função security definer num schema exposto pode ser chamada pela Data API com os privilégios de quem a criou, e diz para nunca criar uma num schema listado em Exposed schemas nas configurações da sua API.
• (select private.is_admin()), embrulhado num select próprio. Isso deixa o Postgres calcular a resposta uma vez para o comando inteiro em vez de uma vez por linha, que é o que a Supabase documenta como motivo para embrulhar auth.uid() do mesmo jeito.

As linhas revoke e grant mantêm a função chamável pelos usuários logados e por mais ninguém.

Essa policy cobre a leitura. Se salvar começar a falhar assim que as suas telas voltarem a encher, você encontrou outra mensagem com outra causa.

O conserto que não conserta

Desligar o Row Level Security em profiles também faz o erro parar, num clique, e entrega cada linha dessa tabela a quem tiver a chave que o seu app envia ao navegador.

Essa chave é feita para ser pública. Ela está no código do seu site, e qualquer pessoa consegue tirá-la de lá em alguns segundos. O que estava impedindo ela de devolver a sua tabela de usuários inteira eram as regras que você acabou de desligar.

O seu app fica com a mesma cara depois nos dois casos, e é essa parte que faz isso ficar. Nada nas suas telas diz qual das duas você escolheu, e o erro sumiu nas duas.

O que diz é o seu banco, perguntado de fora. Escaneamos 31.056 apps no ar feitos com Lovable, Bolt, v0, Replit e os outros, e vimos um projeto Supabase atrás de 8.435 deles. Foi isto que a verificação de Row Level Security encontrou:

A linha do meio é a honesta. Em 4.755 desses apps a verificação não obteve resposta, e dizemos isso em vez de dá-los como limpos. E algumas das 2.096 são para serem lidas mesmo, porque uma tabela pública é uma coisa que se quer de verdade; de fora, um cardápio e uma lista de sócios são iguais.

Não dá para dizer quantas dessas tabelas foram abertas por alguém tirando da frente exatamente este erro. Dá para dizer que uma tabela aberta é o fim comum do conselho que aparece no topo dos resultados de busca.

Se você prefere não ter que pensar nisso, o nosso scan gratuito lê o seu site no ar e diz quais das suas tabelas respondem a um estranho. Leva cerca de 20 segundos e não pede conta: escaneie o seu app.

Mais uma coisa acontece quando você desliga. O próprio advisor da Supabase começa a reportar a tabela, que é o aviso RLS disabled in public, e esse aviso vai continuar lá daqui a um mês.

Como saber se o círculo foi mesmo embora

O erro parar não é o teste, porque duas coisas diferentes fazem ele parar.

Existe ainda um jeito de a função auxiliar parecer certa e continuar recursiva, e a Supabase documenta: uma função security definer só pula as regras se o dono dela puder. Na Supabase o dono é o postgres, que tem esse privilégio, então o padrão acima funciona. Uma função que pertença a um papel sem ele, ou que leia uma tabela com force row level security, volta a passar pela regra e continua no círculo.

Duas conferidas, e faça as duas:

Escreva os casos e rode. O procedimento da Supabase é um arquivo .sql em supabase/tests/ afirmando permissão e recusa para cada operação, para um usuário logado e para um anônimo, rodado com supabase test db. Um admin tem que ver todos os perfis, um membro o dele, um estranho nada. Até isso passar, o que você sabe é que o erro parou.

Depois pergunte de fora, sem login. Essa é a pergunta que o navegador de um visitante faz, e a única que reflete o que o seu app realmente entrega. Se um estranho consegue ler o seu banco mostra o caminho, e Row Level Security pode estar ligado e a tabela continuar pública cobre o caso em que as regras existem e deixam todo mundo passar assim mesmo.

Quando a recursão está dizendo que o schema está errado

Às vezes não há pergunta circular para tirar, porque as duas tabelas dependem mesmo uma da outra.

O guia da Supabase usa compartilhamento como exemplo: uma regra em lists confere list_members para ver com quem a lista foi compartilhada, e uma regra em list_members confere lists para ver de quem ela é. A regra de cada tabela lê a outra, e nenhuma pode ir primeiro. O mesmo auxiliar desfaz isso, com uma função que devolve os ids das listas a que quem chama pertence, e as duas regras perguntando para essa função em vez de perguntarem uma à outra.

O sinal que vale notar é quando você precisa de três ou quatro dessas para um schema funcionar. A essa altura a participação está sendo reconstruída dentro das regras toda vez, e uma única tabela que diga claramente quem pode ver o quê costuma dar menos manutenção do que as regras que você está desembaraçando.

Como manter a tabela fechada depois de consertar

Uma regra que você consertou hoje descreve o banco de hoje. A próxima policy, a próxima tabela e a próxima vez que alguém tira um erro da frente à meia-noite acontecem todas depois da última vez que você olhou, e nenhuma delas muda nada que você consiga ver nas suas telas.

O Reeve Monitor faz ao seu app as mesmas perguntas de novo, com horário:

• as nove verificações a cada hora, em até três apps
• uma mensagem quando um resultado muda, para que uma tabela que abriu de madrugada não espere você notar
• se o app responde, a cada 60 segundos
• um relatório mensal do que ele viu

Se o seu app guarda os dados no seu próprio projeto Supabase, o Reeve Care ainda guarda uma cópia desse banco. Uma regra que deixa um estranho ler é um problema. Uma regra que deixa um estranho escrever é o outro, e nenhuma verificação deste artigo traz linhas apagadas de volta.

• uma cópia criptografada do seu banco Supabase toda noite, guardada onde o seu projeto não alcança
• cada cópia verificada antes de contar, contando as linhas de cada tabela
• uma restauração em um clique quando você precisar
• os seus arquivos enviados também, assim que você conectar uma credencial de Storage
• tudo o que o Monitor faz

O que fazer agora

Se você quer o resto da lista para um app recém-lançado, a checklist de segurança de 10 minutos cobre isto e as outras coisas que vale fechar antes de alguém encontrar.