Como fazer cada pessoa ver só os próprios dados no seu app

Pense em um app com notas, reservas, faturas, mensagens, dados de saúde, informações de clientes ou histórico de pagamento. A pessoa entra esperando ver apenas o que é dela. Se o seu app mostra registros de outra pessoa por engano, ou deixa alguém alterar ou apagar dados de outra conta, o problema não é só confusão. É uma falha real de proteção em um app com vários usuários.

A ideia simples vem antes do nome técnico: todo item salvo precisa estar ligado à pessoa certa, e o app precisa conferir essa ligação sempre que mostrar, criar, alterar ou remover dados. No Supabase, o nome técnico é Row Level Security. Quem programa costuma encurtar para RLS. Você não precisa começar decorando isso. Comece pelo resultado desejado: uma pessoa deve ficar limitada aos próprios registros, não aos de todo mundo.

Muita gente iniciante acha que o perigo só começa quando o app lida com cartão, banco ou dados médicos. Mas até um app simples pode expor informações de clientes, endereços, telefones, notas pessoais, horários de reserva, arquivos enviados ou histórico de pedidos. Se um usuário consegue ver os dados de outro, o app já parece quebrado. Se um usuário consegue editar ou apagar registros de outra pessoa, o estrago fica maior porque a informação pode ser alterada ou perdida.

Por isso o Supabase oferece regras de proteção linha por linha. O nome técnico é Row Level Security. Essas regras servem para olhar cada linha salva e perguntar, na prática, esta linha pertence à pessoa atual? Se sim, permite. Se não, bloqueia. Essa proteção importa em toda tela e em toda ação, não só na primeira página depois da entrada. E ela também importa com o passar do tempo, porque um recurso novo pode escapar das regras que você achava que já cobriam tudo.

Quem está começando costuma testar só o caminho feliz: entra na conta, abre o painel e confirma que parece certo. Mas os problemas aparecem muito nas partes menos óbvias. Talvez a lista esteja filtrada corretamente, mas a edição confie em um número de registro vindo da página. Talvez o botão de apagar funcione em um item de outra conta. Talvez uma tabela nova de comentários ou arquivos enviados tenha sido criada sem salvar quem é o dono de cada linha. Em todos esses casos, o app pode misturar dados entre pessoas mesmo que a tela principal pareça correta.

A regra prática é simples: todo registro que pertence a um usuário deve carregar um vínculo claro com o dono, normalmente o ID da pessoa logada. Depois, toda leitura, criação, alteração e exclusão precisa conferir esse vínculo. Os nomes técnicos são regras de read, insert, update e delete dentro do Row Level Security. Se você usa uma ferramenta de IA para montar o app, peça para ela mostrar essas verificações uma por uma. Você não está procurando palavras bonitas. Está procurando prova de que a conta de uma pessoa não consegue mexer na linha de outra.

Comece pelas tabelas de dados. Encontre cada tabela que guarda informações de usuários individuais. Confirme que cada linha tem um campo claro de dono. Depois pergunte à sua ferramenta de IA onde o Supabase está aplicando as verificações linha por linha. Em seguida, teste com duas contas. O usuário A deve ver apenas os registros de A. O usuário B deve ver apenas os registros de B. Cada um só deve conseguir criar, editar e apagar as próprias linhas. Essa é a verificação prática mais rápida para saber se o seu app está respeitando o limite entre os usuários.

Enquanto faz essa revisão, confira também onde o app guarda senhas, chaves de pagamento e códigos de acesso. Esses itens não devem aparecer em arquivos enviados ao navegador nem em telas públicas. A VibeCodeWall não vê seu código privado por dentro. Ela verifica o app público por fora e acompanha mudanças importantes ao longo do tempo, o que ajuda a perceber arquivos expostos ou mudanças visíveis depois de atualizações. Isso não substitui seus próprios testes de separação por usuário. Funciona melhor junto com eles, como um hábito repetido após cada mudança no app.