supabasesegurançarlsiavibe-coding

Supabase e RLS: a falha que aparece em quase todas as apps feitas com IA

Em Supabase, a chave pública fica no browser — e a única coisa entre ela e os teus dados são as regras de RLS. É também o que mais vezes encontramos mal configurado em apps feitas com IA.

13 de outubro de 2026

Quase todas as apps feitas com Lovable, Bolt ou v0 usam Supabase. É uma excelente escolha: base de dados PostgreSQL, autenticação e armazenamento, prontos em minutos. Mas tem uma particularidade que a maioria dos fundadores não conhece — e que as ferramentas de IA tratam mal com frequência.

A chave pública é mesmo pública

A app fala com a base de dados diretamente a partir do browser, com uma chave pública ("anon", ou "publishable" nos projetos mais recentes) que qualquer pessoa consegue ver no código da página. Isto é intencional: o Supabase foi desenhado assim.

O que torna isto seguro é o Row Level Security (RLS) — regras no PostgreSQL que decidem, linha a linha, o que cada pedido pode ler ou alterar. A documentação do Supabase é clara: o RLS deve estar ativo em todas as tabelas expostas ao browser.

Ou seja: sem RLS, a chave pública dá acesso à tabela inteira.

Os erros que mais encontramos

1. Tabelas sem RLS ativo. A IA cria uma tabela nova para uma funcionalidade e esquece-se de ativar as regras. O Supabase avisa no painel — mas só se alguém for ver.

2. Regras que deixam passar tudo. Durante o desenvolvimento aparece um erro de permissões e a solução mais rápida é uma regra que permite tudo. A funcionalidade passa a funcionar — e a regra fica para sempre.

3. Regras que confiam no utilizador. Em apps com várias empresas, a regra verifica se a linha pertence à empresa indicada no pedido. O problema: quem indica a empresa é o próprio utilizador. A regra tem de usar a identidade autenticada (o auth.uid() e as associações guardadas na base de dados), nunca um valor enviado pelo browser.

4. A chave de serviço no sítio errado. A chave service_role (ou "secret", nos projetos mais recentes) ignora todas as regras. Serve para o servidor, nunca para o browser — mas aparece em código de frontend mais vezes do que devia.

5. Regras corretas, mas lentas. Regras que fazem subconsultas sem índices correm em cada linha de cada consulta. Com dados reais, a app fica lenta e ninguém percebe porquê.

Como verificar a tua app

  • Abre o Security Advisor no painel do Supabase e confirma que não há tabelas sem RLS.
  • Procura no código do frontend por service_role.
  • Cria duas contas de teste em empresas diferentes e tenta ver os dados de uma com a outra.
  • Revê cada regra que contenha true sem condições.

Se algum destes passos te deixar dúvidas, é um bom sinal de que vale a pena alguém olhar com calma.

O que fazemos numa auditoria

Mapeamos as regras tabela a tabela, testamos o acesso como utilizadores diferentes e como alguém de fora, e deixamos testes automáticos às regras na pipeline — para que uma fuga corrigida não volte com a próxima alteração gerada por IA.

Tens uma app em Supabase feita com IA? Faz o diagnóstico de 2 minutos ou marca uma conversa de 30 minutos.


Fonte: Supabase — Row Level Security.

Ver também: Auditoria e correção de apps feitas com IA.

Tens um projecto em mente?

Fala comigo — respondo em menos de 24h.

Entrar em contacto