Row Level Security no Supabase: Guia de Segurança 2026

Row level security no Supabase é o recurso do PostgreSQL que decide, linha por linha, o que cada usuário pode ler ou alterar em uma tabela — funciona como uma cláusula WHERE aplicada automaticamente pelo banco a cada consulta. Sem RLS habilitado, qualquer pessoa com a chave pública (anon key) do projeto pode ler ou escrever em todas as linhas de uma tabela exposta, mesmo sem estar logada. Ativar e configurar corretamente essas políticas é hoje um dos passos mais importantes ao construir qualquer aplicação com Supabase.

##O que é Row Level Security no Supabase

RLS é uma camada de autorização que vive dentro do próprio banco de dados, não no código do frontend ou da API. Isso significa que a regra de acesso vale independentemente de como os dados são consultados — pelo app, por uma chamada direta à API REST gerada pelo Supabase, ou por qualquer outro cliente.

Cada política é uma expressão SQL nomeada, associada a uma tabela e a uma operação específica: SELECT, INSERT, UPDATE ou DELETE. A função auth.uid() identifica o usuário autenticado dentro da política, permitindo regras como "cada usuário só vê os próprios registros".

##Por que habilitar RLS não é opcional

Segundo a documentação oficial do Supabase, toda tabela em um schema exposto pela API precisa ter RLS habilitado, sem exceções — inclusive tabelas que hoje parecem "só de leitura pública". A chave anon cria uma sessão com papel anon; o JWT do usuário logado cria uma sessão autenticada; já a chave service_role ignora RLS por completo e nunca deve chegar ao código do cliente.

Em janeiro de 2026, a plataforma Moltbook expôs cerca de 1,5 milhão de chaves de API porque seu banco Supabase estava com RLS desabilitado em produção — qualquer pessoa com conhecimento técnico básico conseguia acessar e-mails, tokens de autenticação e chaves de API de cada usuário. A correção exigiu apenas duas instruções SQL, mas o vazamento já havia ocorrido. O episódio mostra que a configuração de row level security no Supabase não é um detalhe técnico secundário, é a linha de defesa principal dos dados.

##Como configurar políticas de RLS passo a passo

Configurar row level security no Supabase segue uma sequência simples de aplicar, mas fácil de esquecer em algum detalhe:

1. Habilitar RLS na tabela: ALTER TABLE public.tabela ENABLE ROW LEVEL SECURITY; (tabelas criadas pelo Table Editor do painel já vêm com RLS ativado por padrão; tabelas criadas via SQL direto, não).
2. Criar uma policy de leitura: por exemplo, permitir que o usuário veja apenas o próprio perfil com CREATE POLICY "ver proprio perfil" ON public.profiles FOR SELECT TO authenticated USING (auth.uid() = id);.
3. Criar uma policy de escrita: usando a cláusula WITH CHECK para garantir que o usuário só insira ou atualize linhas que pertencem a ele.
4. Testar com usuários reais: simular login com diferentes contas para confirmar que cada uma enxerga só o que deveria.
5. Automatizar os testes: ferramentas como pgTAP ajudam a detectar regressões de política antes de qualquer deploy.

Em aplicações multi-tenant (várias empresas ou times no mesmo banco), o padrão mais comum combina auth.uid() com uma tabela de vínculo entre usuário e organização, evitando que uma consulta mal escrita vaze dados entre clientes diferentes.

##Erros comuns que colocam o banco em risco

Alguns problemas aparecem com frequência em projetos reais:

• Deixar tabelas novas sem RLS habilitado, achando que "vai ativar depois".
• Usar a service_role key em código que roda no navegador, ignorando toda a proteção de RLS.
• Escrever policies genéricas demais (USING (true)) por pressa, liberando acesso total sem perceber.
• Não testar policies com múltiplos usuários antes de ir para produção.
• Confundir autenticação (quem é o usuário) com autorização (o que ele pode acessar) — RLS resolve a segunda parte, não a primeira.

Corrigir esses pontos antes do lançamento custa muito menos do que remediar um vazamento depois.

##Perguntas Frequentes

RLS deixa o banco mais lento? Policies bem escritas, com índices adequados nas colunas usadas em USING, têm impacto mínimo. Policies mal otimizadas é que costumam gerar consultas lentas.

Preciso de RLS se meu app já valida tudo no backend? Sim. RLS protege o dado mesmo se houver falha, bug ou acesso direto à API — é uma camada extra, não um substituto da validação de aplicação.

A chave anon do Supabase pode ficar exposta no frontend? Sim, ela é feita para isso, desde que todas as tabelas acessadas por ela tenham RLS habilitado e políticas corretas. Sem RLS, expor a anon key é arriscado.

Como faço RLS multi-tenant sem duplicar lógica em cada tabela? Centralize a checagem em uma função SQL reutilizável (security definer function) que verifica o vínculo do usuário com a organização, e chame essa função dentro das policies.

Existe ferramenta para testar policies automaticamente? Sim, pgTAP é a opção mais usada para testes automatizados de RLS dentro do próprio Postgres, integrável ao pipeline de CI/CD.

##Conclusão

Row level security no Supabase é a diferença entre um banco protegido e um banco exposto por padrão. Habilitar RLS em toda tabela, escrever policies específicas e testar com usuários reais antes do deploy evita boa parte dos incidentes de segurança que aparecem em produção. Para quem constrói produtos com Supabase, Netlify e o stack de React, esse cuidado técnico é parte do trabalho de qualquer agência séria — e é esse tipo de fundação sólida que a Stormcore aplica ao criar sites, sistemas e automações para seus clientes.