O Supabase não é o problema. É uma ferramenta sólida, construída em cima de Postgres de verdade, e funciona muito bem pra maioria dos produtos. O problema é que, por padrão, um projeto novo nasce com o banco aberto pra leitura e escrita, e a proteção real (chamada RLS, Row Level Security) precisa ser ativada e configurada tabela por tabela. Quando o sistema é montado rápido com apoio de IA, essa etapa quase sempre fica pra trás.
O teste abaixo não altera nada no seu sistema. Ele só usa a mesma chave pública que o site já expõe pra qualquer visitante e mostra o que essa chave consegue enxergar.
Passo 1: encontre a chave pública do seu sistema
Abra o site do seu sistema no navegador, aperte F12
(ou clique com o botão direito e escolha "Inspecionar") pra abrir as
ferramentas de desenvolvedor, vá na aba Network
(Rede) e recarregue a página. Procure uma requisição com
supabase.co no endereço, clique nela e olhe os
cabeçalhos: tem um campo chamado apikey. Copie esse
valor.
Isso é normal e esperado, essa chave é pública por design, todo site que usa Supabase no navegador precisa expor ela. O que não pode estar exposto é a chave de serviço (service role), que é diferente e dá acesso total sem restrição nenhuma. Se você achar essa segunda no código do site, é um problema grave e imediato.
Passo 2: tente ler uma tabela que não deveria ser pública
Com a chave pública em mãos, monte uma URL assim no navegador
(trocando SEU-PROJETO e NOME-DA-TABELA
pelos valores reais, por exemplo usuarios,
pedidos ou clientes):
https://SEU-PROJETO.supabase.co/rest/v1/NOME-DA-TABELA?select=*&apikey=SUA-CHAVE-AQUI
Se a resposta vier com uma lista de dados de outras pessoas, nomes, e-mails, pedidos que não são seus, a tabela está sem RLS ou com RLS mal configurada, e qualquer visitante do site consegue ler tudo isso da mesma forma. Se vier vazia ou com uma mensagem de erro de permissão, é um bom sinal.
E se der pra ler, dá pra escrever também?
Esse é o teste que realmente separa um susto de um problema grave: se a mesma chave também permite alterar dado de outra pessoa, não só ler. Esse teste tem risco real, pode alterar dado de produção se a falha existir, e exige saber exatamente o que está sendo enviado e pra onde. Não é algo pra fazer sozinho tentando adivinhar, é exatamente esse tipo de verificação controlada que fazemos numa auditoria, sem colocar seu sistema em risco no processo.
Achou uma tabela aberta? Não corrija no escuro
Ativar RLS sem entender exatamente quais políticas o seu sistema precisa costuma trocar um problema por outro: em vez de dado exposto, o sistema para de funcionar pra todo mundo, inclusive pros usuários legítimos. É um erro comum tentar resolver isso copiando um exemplo genérico da internet sem mapear como o seu sistema realmente usa cada tabela.
Se você rodou o teste acima e a resposta veio com dados que não são seus, o próximo passo certo não é sair mexendo em produção por conta própria. É mapear com cuidado o que corrigir e como, sem tirar o sistema do ar no processo, e isso é justamente o que fazemos numa auditoria.
Por que isso é tão comum
Numa auditoria interna que fizemos em sete sistemas próprios e de clientes, encontramos falhas de permissão em bancos de dados Supabase em mais de uma ocasião, incluindo um caso onde funções do banco aceitavam o ID de qualquer usuário como parâmetro livre, sem nunca conferir se quem chamava era realmente aquele usuário. Contamos esse caso, sem identificar o sistema, no relato da nossa auditoria interna.