Conectar o Supabase à Lovable resolve banco de dados, autenticação e backend rapidamente. Mas existe uma etapa que não deve ser tratada como detalhe: garantir que um usuário não consiga consultar ou alterar os dados de outro. É exatamente aí que entra o RLS.
Por que RLS importa em um projeto Lovable
Apps criados na Lovable normalmente acessam o Supabase pelo frontend usando uma chave publicável. Essa chave identifica o projeto, mas não é uma senha que protege cada registro. A proteção real dos dados expostos pela Data API vem das permissões do Postgres combinadas com as políticas de RLS.
Entenda o modelo antes de criar políticas
- Autenticação confirma quem é o usuário
- O JWT carrega a identidade da sessão
- RLS usa essa identidade para decidir quais linhas podem ser acessadas
- Uma policy funciona como um filtro aplicado às operações no banco
- A service role ignora RLS e nunca deve ficar no frontend
Passo 1: identifique quais tabelas guardam dados de usuários
Comece pelas tabelas que armazenam informações privadas ou pertencentes a uma conta: perfis, pedidos, projetos, tarefas, mensagens, documentos, agendamentos e dados financeiros. Para cada uma, responda: quem é o dono desta linha?
Passo 2: habilite RLS nas tabelas expostas
No Supabase, abra a área de políticas da tabela e confirme que Row Level Security está habilitado. Tabelas criadas pelo Table Editor normalmente já recebem RLS por padrão; tabelas criadas por SQL ou outros fluxos precisam ser verificadas.
Passo 3: crie a regra de leitura por usuário
Para uma tabela em que cada registro pertence a um usuário, a regra mais comum compara auth.uid() com a coluna user_id. Em linguagem simples: o usuário autenticado só pode selecionar linhas cujo dono seja ele mesmo.
Passo 4: proteja também criação, edição e exclusão
Uma policy de leitura não protege automaticamente INSERT, UPDATE e DELETE. Para inserir, valide que o user_id do novo registro pertence à sessão. Para atualizar, use uma condição para a linha existente e outra para garantir que a linha resultante continue pertencendo ao mesmo usuário. Para excluir, restrinja a operação ao dono do registro.
- SELECT: usuário lê apenas as próprias linhas
- INSERT: novo registro precisa pertencer ao usuário autenticado
- UPDATE: usuário só altera a própria linha e não pode trocar o proprietário
- DELETE: usuário só remove a própria linha
Passo 5: peça à Lovable para implementar com contexto
O prompt funciona melhor quando você informa quais dados devem ser públicos e quais são privados. Não peça apenas para deixar o banco seguro: descreva quem deve poder fazer o quê.
Nem toda tabela precisa ser privada
Um catálogo público, posts publicados ou configurações que todos podem ler podem ter políticas diferentes. RLS não significa bloquear tudo; significa transformar a regra de negócio em autorização explícita. Uma tabela pode permitir leitura pública e restringir escrita a usuários autorizados.
Como testar RLS antes de publicar o app
- Crie dois usuários de teste diferentes
- Entre como o usuário A e crie um registro
- Confirme que o usuário A consegue ler e editar o próprio registro
- Entre como o usuário B
- Tente acessar o registro criado pelo usuário A
- Teste criação, edição e exclusão com ambos
- Repita o teste nas tabelas que guardam dados sensíveis
Ver a interface funcionando não prova que o banco está protegido. O teste precisa confirmar que uma sessão autenticada não consegue acessar linhas de outro usuário mesmo tentando consultar a tabela diretamente pelo fluxo do aplicativo.
Erros comuns de RLS em projetos Lovable
- Habilitar RLS e esquecer de criar as policies necessárias
- Criar policy para SELECT e esquecer UPDATE ou DELETE
- Usar uma condição aberta em tabela com dados privados
- Confiar apenas em esconder botões na interface
- Usar user_metadata como base de autorização sensível
- Colocar service role ou secret key no frontend
- Não testar com dois usuários diferentes
- Criar UPDATE sem a política de SELECT correspondente
Por que UPDATE costuma confundir
O Supabase documenta que uma operação UPDATE também precisa de uma policy de SELECT correspondente para funcionar como esperado. Além disso, é recomendável validar tanto a linha atual quanto o resultado da atualização, evitando que alguém troque o user_id e transfira um registro para outra conta.
Nunca coloque service role no frontend da Lovable
A chave de service role ou uma secret key é destinada a ambientes confiáveis de backend e pode ignorar RLS. No navegador, use a chave publicável apropriada e deixe as políticas decidirem o acesso com base na sessão. Segredos administrativos devem ficar em backend ou secrets.
Já conectou Supabase? Fortaleça o projeto em vez de refazer
Se você ainda está configurando banco, login e backend, comece pelo guia Como conectar Supabase na Lovable: https://lovacademy.com.br/blog/como-conectar-supabase-na-lovable. Depois volte a este checklist de RLS antes de trabalhar com usuários reais.
Se seu projeto usa Edge Functions ou será publicado fora da plataforma, veja também o guia de deploy e Supabase: https://lovacademy.com.br/blog/deploy-lovable-vercel-edge-functions-supabase.
Checklist de RLS para vibe coders
- Mapeei as tabelas com dados privados
- Cada linha privada possui uma forma clara de identificar o dono
- RLS está habilitado nas tabelas expostas
- SELECT está restrito corretamente
- INSERT valida o proprietário
- UPDATE possui USING e WITH CHECK adequados
- DELETE está restrito
- Nenhuma service role está no frontend
- Testei o app com pelo menos dois usuários
- Revisei tabelas públicas separadamente
Fontes oficiais
- Supabase Docs — Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
- Supabase Docs — Securing your API: https://supabase.com/docs/guides/api/securing-your-api
- Supabase Docs — Securing your data: https://supabase.com/docs/guides/database/secure-data
