Conhecer a Grimpo
Apps com IA

Supabase e Firebase sem regras de acesso: quando qualquer usuário lê o banco inteiro

Equipe Grimpo · 5 min de leitura · 3 de novembro de 2026

Supabase e Firebase sem regras de acesso: quando qualquer usuário lê o banco inteiro

Boa parte dos apps criados com Lovable, Bolt e ferramentas parecidas usa Supabase ou Firebase como banco de dados. A escolha faz sentido: os dois permitem que o app no navegador leia e grave dados diretamente, sem precisar de um servidor intermediário. Isso acelera muito a construção.

Mas essa arquitetura tem uma consequência que muita gente só descobre tarde: se o navegador fala direto com o banco, quem decide o que cada usuário pode ver é o banco. Não a tela. Não o botão escondido. O banco.

O problema em uma frase

Quando as regras de acesso não estão escritas, ou estão escritas de um jeito permissivo demais, qualquer usuário logado (e às vezes qualquer pessoa) consegue pedir ao banco os dados de todos os outros usuários. A tela do app pode mostrar só “os meus pedidos”, mas o banco entrega todos os pedidos para quem pedir do jeito certo.

Supabase: Row Level Security

No Supabase, o mecanismo se chama Row Level Security (RLS), um recurso do próprio PostgreSQL. Com o RLS ligado numa tabela, nenhuma linha é entregue a não ser que uma política (policy) permita. Você escreve, por exemplo: “um usuário só pode ler as linhas em que a coluna user_id é igual ao id dele”.

Os erros que mais encontramos:

  • RLS desligado em uma ou mais tabelas. A tabela fica aberta para quem tiver a chave pública, que está, por definição, no navegador.
  • Política “libera tudo”, do tipo using (true), criada pela IA para fazer uma tela funcionar rapidamente. Na prática, é o mesmo que não ter RLS.
  • Política só para leitura, esquecendo inserção, atualização e exclusão. O usuário não vê os dados alheios, mas consegue alterá-los.
  • Tabela de perfis com campo de papel (role, is_admin) que o próprio usuário consegue editar. Basta mudar o próprio cadastro para virar administrador.
  • Uso da chave service_role no navegador, que ignora todas as políticas.

Firebase: Security Rules

No Firebase (Firestore, Realtime Database e Storage), o equivalente são as Security Rules. Os erros são parecidos:

  • Regras do modo de teste, que liberam leitura e escrita para todo mundo por um período. Muita gente esquece de trocar quando o período acaba ou estende o prazo.
  • Regras que verificam só se o usuário está logado (request.auth != null), sem verificar se o documento pertence a ele.
  • Storage aberto, com fotos e documentos de usuários acessíveis por qualquer link.

Como testar o seu app

Você não precisa ser especialista para fazer o teste básico:

  1. Crie duas contas de teste, A e B.
  2. Com a conta A, cadastre algum dado (um pedido, um perfil, um documento).
  3. Entre com a conta B e tente acessar o dado de A: troque o id na URL, procure na lista, tente editar.
  4. No Supabase, abra o painel e veja o Security Advisor, que lista tabelas expostas sem RLS. No Firebase, use o simulador de regras do console para testar leitura e escrita com usuários diferentes.

Se a conta B conseguiu ver ou alterar qualquer coisa de A, as regras precisam ser corrigidas antes de qualquer outra coisa.

Como corrigir sem quebrar o app

Ligar o RLS sem escrever as políticas bloqueia tudo: o app para de mostrar dados e parece que quebrou. Por isso a ordem é:

  1. Liste as tabelas e quem deve acessar cada uma. Dados do próprio usuário, dados compartilhados por uma equipe, dados públicos, dados só de administrador.
  2. Escreva as políticas para cada operação (ler, criar, alterar, apagar), baseadas no usuário logado (auth.uid() no Supabase, request.auth.uid no Firebase).
  3. Proteja os campos sensíveis. Papel, plano e permissão não podem ser editados pelo próprio usuário. Se precisar, mova para uma tabela separada que só o servidor altera.
  4. Teste num ambiente separado com as contas A e B, incluindo as tentativas de acesso indevido.
  5. Publique e repita o teste em produção.

Por que isso é mais grave do que parece

Um vazamento de dados não é só um problema técnico. Pela LGPD, quem trata dados pessoais responde pela segurança deles e precisa comunicar à ANPD e aos titulares os incidentes que possam gerar risco ou dano relevante. Se o app guarda dados de saúde, financeiros ou de crianças, o cuidado precisa ser ainda maior.

A boa notícia: esse é um dos problemas mais baratos de corrigir quando encontrado cedo. As regras de acesso são poucas linhas por tabela. O caro é descobrir depois.

Escrito pela equipe da Grimpo com apoio de inteligência artificial e revisado por uma pessoa. Viu um erro ou quer sugerir um tema? Fale com a gente.

Perguntas frequentes

Como sei se o RLS está ligado no meu Supabase?

No painel do Supabase, em Table Editor ou Authentication > Policies, cada tabela mostra se o RLS está ativado. O próprio painel também aponta tabelas públicas sem RLS no Security Advisor.

Ligar o RLS quebra o app?

Ligar sem escrever políticas bloqueia tudo, e o app para de mostrar dados. Por isso o certo é escrever as políticas primeiro, testar em um ambiente separado e só então ligar em produção.

Regras no front-end não bastam?

Não. Esconder um botão ou filtrar a lista na tela não impede ninguém de pedir os dados direto ao banco. A regra precisa estar no banco.

Fontes

Continue lendo