Segurança no Supabase: O Perigo Oculto do RLS Mal Configurado (E como testar)

O Supabase revolucionou a forma como construímos aplicações. Sendo a alternativa Open Source mais robusta ao Firebase, ele entrega um banco de dados PostgreSQL real emparelhado com uma API instantânea (PostgREST). É rápido, moderno e incrivelmente poderoso.

No entanto, com grandes poderes vêm grandes responsabilidades. A facilidade de ter uma API que reflete diretamente as tabelas do seu banco de dados traz um risco cibernético gigantesco se você ignorar um conceito fundamental: o RLS (Row Level Security).

Neste artigo, vamos entender como os vazamentos de dados ocorrem em projetos Supabase e como você pode auditar a sua própria aplicação antes que um usuário mal-intencionado o faça.

O que é o RLS (Row Level Security)?

Diferente de APIs tradicionais em Node.js ou Laravel, onde você escreve a lógica de controle de acesso (ex: if (user.id !== post.author_id) return 403), no Supabase o controle de acesso não fica no código do servidor, mas sim dentro do próprio banco de dados.

O PostgreSQL permite que você crie Políticas de Segurança em Nível de Linha (RLS). Isso significa que, toda vez que uma requisição bate na sua API, o banco de dados atua como um leão de chácara invisível, filtrando quais linhas aquele usuário específico tem permissão para ler, inserir, atualizar ou deletar.

O grande problema (A armadilha do Default)

Por padrão, quando você cria uma tabela nova no Supabase, o RLS vem desativado. Isso significa que a tabela é 100% pública. Qualquer pessoa na internet com a sua anon_key (que fica exposta no código-fonte do seu frontend) pode fazer um GET e baixar o seu banco de dados inteiro.

Os 3 Erros Fatais de Segurança no Supabase

Mesmo quando os desenvolvedores lembram de ativar o RLS, é comum cometerem erros de lógica nas políticas. Os maiores riscos são:

1. Permitir acesso “Anon” indiscriminado

Muitos tutoriais ensinam a criar políticas do tipo true para a regra de SELECT. O resultado? Você protegeu quem pode editar os dados, mas deixou a leitura aberta para o mundo. Dados sensíveis de clientes, como e-mails e telefones, ficam expostos para qualquer crawler ou bot.

2. Esquecer de validar o “Ghost Auth”

Se o seu aplicativo não exige a confirmação de e-mail (Enable Email Confirmations), um atacante pode forjar uma requisição de SIGNUP direto na API com um e-mail falso. Ao fazer isso, o Supabase gera um token JWT válido com a role authenticated. Se as suas regras de RLS confiam cegamente em qualquer usuário autenticado, o atacante acaba de ganhar as chaves do castelo.

3. A vulnerabilidade de “Mass Assignment”

Imagine que a sua tabela users tenha uma coluna chamada is_admin. Se a sua regra de UPDATE (PATCH) permite que o usuário atualize a própria linha, o que impede ele de enviar um payload contendo {"is_admin": true}? Se você não bloquear colunas específicas, o usuário pode escalar os próprios privilégios facilmente.

Como testar a segurança da sua API na prática?

Validar essas brechas manualmente exige muito trabalho. Você precisaria abrir o Postman, capturar a anon_key no console do navegador, forjar requisições de Auth, pegar o Bearer Token, mapear todas as rotas de tabelas e testar método por método (GET, POST, PATCH, DELETE).

Para resolver esse ponto cego, profissionais de Red Team e desenvolvedores estão adotando ferramentas de DAST (Dynamic Application Security Testing) focadas exclusivamente na arquitetura PostgREST.

A ferramenta mais completa e cirúrgica do mercado atualmente é o SupaSec.

O que o SupaSec faz?

O SupaSec é um auditor de segurança e extrator de dados totalmente focado em ecossistemas Supabase. Em vez de testar rotas no escuro, ele automatiza o trabalho de um Pentester avançado:

1. Descoberta Automática: Ao inserir a URL do seu app, ele varre os bundles de JavaScript do seu frontend, extrai sua URL do Supabase e a Chave Pública Anon.
2. Ghost Auth Exploit: Ele tenta criar um usuário “fantasma” na sua API para burlar regras de RLS que exigem apenas que o usuário esteja autenticado.
3. Data Dumping Inteligente: Ele mapeia o Swagger da sua API, descobre todas as tabelas ocultas e tenta extrair os registros bypassando limites de paginação. Se uma tabela retornar dados, seu RLS está vulnerável.
4. Exploit Mode Seguro (Dry-Run): O SupaSec permite que você teste ataques de PATCH e DELETE diretamente pela interface dele. O diferencial? Ele usa o cabeçalho Prefer: tx=rollback, o que significa que ele simula o ataque, verifica se a escalada de privilégio funcionou, e desfaz a transação no banco de dados em milissegundos, evitando qualquer corrupção nos dados reais de produção.

Passo a passo para blindar seu Banco de Dados

Não espere um vazamento de dados acontecer para levar a segurança a sério. Siga este checklist hoje mesmo:

1. Ative o RLS em absolutamente todas as tabelas do painel do Supabase.
2. Crie políticas baseadas no UUID do usuário (auth.uid() = user_id).
3. Vá nas configurações de Autenticação e ative o “Confirm email”. Isso impede a criação de contas fantasmas silenciosas.
4. Acesse o SupaSec, coloque a URL do seu site e veja se o robô consegue extrair suas tabelas.

A regra da cibersegurança moderna é clara: Se você não atacar o seu próprio sistema para encontrar as falhas, alguém fará isso por você.