RLS no Supabase: proteja o SaaS já hoje

O que é Row Level Security (RLS) no Supabase

RLS, ou Row Level Security, é um recurso que protege cada linha da sua tabela no Supabase/Postgres. Quando ativada, apenas registros que atendem às regras de segurança definidas podem ser acessados ou modificados por determinado usuário.

Por que muitos projetos SaaS ficam expostos

É comum encontrar projetos usando Supabase sem encadeamento correto de políticas. Muitas vezes, apps vão para produção sem configurações mínimas de proteção, resultando em APIs completamente abertas a qualquer um que adivinhe a URL e a chave.

Como funciona a exposição de dados no Supabase

Supabase utiliza uma API REST onde o endpoint, nomes de tabelas e chaves públicas ficam aparentes nas requisições de rede. Estas informações, por si só, não representam risco. O perigo está em tabelas ou endpoints sem políticas de acesso, pois qualquer usuário pode manipular os dados.

Demonstração prática: diferença entre tabelas protegidas e expostas

Ao inspecionar o app pelo navegador, qualquer pessoa pode simular requisições para acesso ao banco. Quando uma tabela está sem RLS, basta passar a chave pública correta para ter acesso total. Em contrapartida, ao ativar RLS, todo acesso deve ser autorizado por políticas, independentemente do uso de token público ou tools como Postman ou HTTP client!

Configuração de RLS e diferença entre “ativar” e “criar política”

Ativar RLS faz com que a tabela pare de liberar dados automaticamente, mas nada será lido/escrito até que políticas explícitas sejam adicionadas. Há diferença entre “RLS ativada” e “política criada”: só criar a política viabiliza acesso granular controlado.

Como criar políticas de acesso seguro no Supabase

Ao criar uma política em sua tabela, você decide: quais operações cada usuário pode executar e sob quais condições. O mais comum é liberar leitura apenas para usuários autenticados.

Restrinja o acesso: só o dono do dado pode ler registro sensível

Apenas liberar para autenticados não é suficiente: qualquer usuário do sistema poderia enxergar dados de outros. O ideal é criar regras para que somente o dono (user_id) do registro consiga acessá-lo.

Como o token de acesso funciona em APIs protegidas

Depois de autenticado, o usuário recebe um access token . Para conseguir acessar dados protegidos, qualquer requisição precisa enviar esse token como “Authorization” no header. Só assim a política de leitura (e outras) irá liberar as informações de acordo com o dono do registro.

Erros comuns e consequências de políticas mal configuradas

Erros como deixar tabelas inteiras sem RLS, criar políticas com true sem filtrar por usuário, enviar dados sensíveis sem restrição ou esquecer de limitar as permissões de cada operação (leitura, escrita, atualização) podem causar vazamento de informações, golpes e exclusão total do banco.

Boas práticas ao modelar tabelas seguras

Sempre que criar uma tabela que contenha dados sensíveis, inclua um campo user_id associando aquele registro ao usuário criador. Assim, suas políticas sempre terão uma condição para identificar o dono do dado.

Cuidados extras: funções administrativas e manipulação via funções RPC

Tabelas extremamente protegidas não podem ser manipuladas nem por usuários autenticados, só via funções administrativas (RPC). Essas funções são úteis para casos como integrações com serviços externos (ex: Stripe) ou ações oriundas do backend da sua aplicação.

Ferramentas para testar e validar políticas de segurança

Use ferramentas como Postman, Insomnia, NHN ou o próprio painel do Supabase para testar todos os tipos de requisições permitidas e bloqueadas, com e sem autenticação, diferentes usuários e tokens.

Perguntas frequentes

Políticas de cache: o que importa?

TTL, invalidação e quem é a fonte da verdade. Header decorativo não salva.

CDN vs app cache?

Camadas diferentes. Confundir gera bug fantasma.

Next.js?

Entenda o modelo da sua versão.

Como debugar?

Reproduza com cache bypass e headers.

Continue explorando