Garanta que Cada Cliente Veja Apenas as Próprias Informações

Imagine que seu app guarda agendamentos, pedidos, anotações, mensagens ou dados de muitas pessoas. Cada cliente espera ver apenas os próprios itens depois de entrar na conta. Essa separação precisa funcionar em todos os lugares: na tela principal, nos resultados da busca, em um item aberto por um endereço salvo e quando o app carrega informações sem mostrar uma nova tela. Esconder os itens dos outros clientes em uma única tela não basta. O local que guarda os dados deve conferir quem está pedindo sempre que algo for visto ou alterado.

O Supabase consegue fazer essa conferência em cada registro salvo. O nome técnico é Row Level Security, muitas vezes abreviado como RLS. Nesse nome, row significa um registro, como um pedido ou uma anotação. Quando a proteção está configurada corretamente, o Supabase compara a conta conectada com o dono daquele registro antes de permitir uma ação. Assim, a separação continua valendo mesmo quando a ferramenta de IA adiciona uma tela ou uma busca.

Para informações pessoais, todo registro salvo deve conter a identidade da conta dona dele. Essa identidade deve vir da conta conectada naquele momento. Ela não deve vir de um nome, email ou número de dono enviado por uma página, pois a pessoa pode alterar esses campos ou a ferramenta de IA pode ligá-los de forma errada. Quando alguém cria uma anotação, um pedido ou uma informação de perfil, o app deve associar automaticamente o item à conta conectada.

Informações compartilhadas precisam de uma organização um pouco diferente. Um projeto pode pertencer a um espaço de trabalho com várias pessoas. Mantenha uma lista protegida indicando quais contas pertencem a cada grupo e o que cada pessoa pode fazer. O nome técnico de uma regra salva que decide se uma ação é permitida é política de banco de dados. Uma boa política tem uma explicação simples: a pessoa é dona do registro, participa do grupo aprovado ou possui uma função interna claramente definida.

Pense separadamente em quatro ações: ver um item, criar um, alterar um e apagar um. Um cliente pode abrir um pedido de ajuda e lê-lo depois, enquanto somente a equipe aprovada pode mudar seu andamento. Um integrante pode ler uma tarefa compartilhada sem poder apagar o projeto inteiro. Quando uma regra ampla cobre tudo, alguém pode ganhar mais poder do que você pretendia.

No Supabase, ative a proteção que confere os registros em todas as tabelas com informações de clientes ou da empresa. Depois, crie uma regra limitada para cada ação permitida. Os desenvolvedores chamam essas regras de políticas. Para um registro pessoal, a política deve comparar a conta conectada com o dono salvo. Para um registro compartilhado, também deve confirmar a participação no grupo certo. Os poderes da equipe devem depender de uma função protegida, e não apenas de um botão escondido. Se nenhuma regra clara permitir uma ação, ela deve ser recusada.

Crie duas contas de teste que representem clientes diferentes, como Alex e Sam. Dê a cada conta anotações, pedidos ou agendamentos de exemplo com nomes claros. Entre como Alex e confirme que os itens de Sam não aparecem em listas, buscas, telas de detalhes, downloads ou áreas de arquivos. Tente alterar e apagar somente pelos recursos normais existentes no app e confirme que os itens de Sam continuam indisponíveis. Depois, repita as mesmas verificações na conta de Sam.

Os desenvolvedores chamam isso de teste de acesso: confirmar que as ações permitidas funcionam e as proibidas são recusadas. Repita o teste sempre que a ferramenta de IA adicionar uma tabela, busca, opção de compartilhamento, exportação, área de arquivos ou função de equipe. Teste também uma conta que participa de um grupo compartilhado e outra que não participa. Uma tela bonita pode esconder uma regra incompleta. Por isso, anote a conta usada, a ação tentada, o resultado esperado e o resultado obtido.

O aparelho do visitante pode precisar de uma configuração pública limitada para o app conversar com o Supabase. Isso não é igual a uma senha de administrador do banco, uma chave de pagamento ou um código que abre muitos registros ou permite gastar dinheiro. Os arquivos enviados ao visitante podem ser examinados e copiados. Senhas e chaves poderosas devem ficar em uma parte protegida do app que funciona longe do aparelho do visitante. Os desenvolvedores chamam esse local protegido de servidor.

Nunca use uma chave poderosa como solução rápida para uma regra de dono que está faltando. No Supabase, uma chave especialmente poderosa tem o nome técnico de service role key; ela consegue ignorar as conferências normais dos registros e nunca deve aparecer nos arquivos enviados a visitantes. Substitua toda senha ou chave exposta, pois apenas mudá-la de lugar não apaga as cópias já feitas. Depois da publicação, o VibeCodeWall pode conferir o app público por fora e acompanhar mudanças importantes ao longo do tempo. Ele não vê código privado, então mantenha também os testes de contas e as revisões no Supabase.