Supabase RLS com exemplos: como impedir que um usuário veja dados alheios
Publicado em 2026-10-26 por frfrand
Políticas RLS práticas com auth.uid e testes de permissões
Você tem uma tabela de notas com user_id. Se a API devolve todas as notas e o frontend apenas filtra as próprias, qualquer usuário curioso pode solicitar dados alheios. A Segurança em Nível de Linha (RLS) permite aplicar políticas no PostgreSQL para restringir linhas.
A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo à produção.
O que o RLS do Supabase faz na prática
O Supabase usa PostgreSQL e sua integração de autenticação pode expor o identificador do usuário por meio de auth.uid() no contexto correto. O RLS requer ser habilitado em cada tabela exposta e definir políticas para SELECT, INSERT, UPDATE e DELETE que correspondam.
Não basta repetir uma receita se você não entender quem lê os dados, de qual processo e com quais permissões. Em um aplicativo com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave do que uma API lenta.
Um exemplo concreto
ALTER TABLE public.notas ENABLE ROW LEVEL SECURITY;
CREATE POLICY "leer notas propias"
ON public.notas FOR SELECT TO authenticated
USING (user_id = (SELECT auth.uid()));
CREATE POLICY "crear notas propias"
ON public.notas FOR INSERT TO authenticated
WITH CHECK (user_id = (SELECT auth.uid()));Os nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de teste e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de amostra sobre dados de clientes sem revisar o que elas modificam.
Passo a passo
- Adicione uma coluna proprietária
user_idde tipo compatível com o identificador do Auth. - Habilite o RLS na tabela exposta e defina uma política SELECT mínima.
- Crie políticas de INSERT/UPDATE separadas que verifiquem o proprietário correto.
- Teste com dois usuários distintos e um não autenticado, não apenas com admin.
- Não exponha a service role key no navegador: ela pode pular controles de RLS.
No final, não fique com «o SQL não deu erro». Verifique o efeito real pela API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.
Exemplo de projeto de trabalho
Em uma plataforma de aulas, cada aluno vê suas reservas. Se o frontend receber todos os registros e filtrar por cliente, o RLS pode evitar leituras não autorizadas quando a solicitação for feita com o papel e JWT adequados.
Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não serve se permitir criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.
O erro típico
O papel service_role no Supabase costuma burlar o RLS; usá-lo acidentalmente pelo cliente anula o modelo. As políticas dependem do esquema e das permissões SQL: teste todas as operações com papéis reais.
Também convém ter um plano de recuperação. Antes de tocar esquema, usuários ou políticas, faça uma cópia verificável ou migração reversível e comprove que o aplicativo possa continuar funcionando durante a mudança.
Como resolveria com ArduMaker?
Outra opção é uma API Django ou FastAPI e PostgreSQL no ArduMaker com autorização implementada no backend. Não é equivalente automaticamente ao Supabase Auth + RLS: você teria que projetar e testar essas regras.
O ArduMaker permite implantar serviços a partir do Git e trabalhar com bancos e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem ficar corretamente projetadas no código e no banco de dados.
Três verificações antes de publicar
Integridade: se uma solicitação for repetida ou falhar no meio do caminho, os dados terminam em um estado válido?
Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco com permissões mínimas?
Recuperação: você sabe restaurar os dados e reverter a versão de código compatível se uma atualização der errado?
Se você puder responder a essas três perguntas com testes, seu backend está bastante mais preparado do que quando você apenas olhou se o endpoint devolvia 200.
Recursos para aprofundar
Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.