RLS na prática: a regra que não tem exceção

Se tem um post desta série que é pra ler duas vezes, é este. Row Level Security (RLS) é a regra de segurança mais importante do nosso banco — e a que vibe coding mais ameaça, porque é fácil a IA criar uma tabela e esquecer dela. Aqui não tem "depois eu ligo".

Por que RLS é obrigatório aqui

O Supabase é PostgreSQL com API automática (PostgREST). Isso significa que a chave anon/authenticated expõe via API qualquer tabela que não tenha RLS. Traduzindo:

Tabela sem RLS = vazamento de dados. Ponto.

Não é teoria. É a porta dos fundos aberta pra qualquer um com a chave pública ler sua tabela inteira.

As três regras da casa

1. Ative RLS em toda tabela

ALTER TABLE <tabela> ENABLE ROW LEVEL SECURITY; no mesmo migration que cria a tabela. Vale pra db:push, migration à mão ou criação no Supabase Studio. Sem "por enquanto".

2. Defina policies explícitas

RLS sem policy = deny-all (ninguém acessa via API). Então:

• Tabela exposta à API → precisa de policy explícita.
• Tabela interna (cache, log, job) → ativa RLS e fica sem policy de propósito (deny-all intencional).

3. Bloqueie no review

PR que cria tabela sem ENABLE ROW LEVEL SECURITY deve ser barrado. É critério de merge, não sugestão.

Onde o vibe coding precisa de coleira

A IA é ótima pra gerar tabela — e é exatamente por isso que o risco existe: ela gera a tabela e, se você não exigir, não gera o RLS. Por isso:

• Inclua RLS no prompt. "Cria a tabela X com RLS habilitado e policy de leitura por organização."
• Revisão dobrada em qualquer coisa de schema. Erro de RLS não é bug, é incidente de segurança.
• Confie no CLAUDE.md. Ele documenta a regra, então o Claude Code já entra avisado — mas a responsabilidade final de checar é sua.

Um lembrete honesto: temos dívida aqui

Auditoria interna apontou tabelas e schemas sem RLS no nosso próprio banco — há um trabalho de remediação em andamento. Ou seja: nem nós estamos 100%. Isso reforça, não enfraquece, a regra. Toda tabela nova nasce certa pra não aumentar a dívida.

⚠️ Armadilha #20: deixar a IA criar tabela e seguir a vida sem checar o RLS. Funciona em dev, vaza em produção. A pergunta depois de toda tabela nova é uma só: "o RLS está ligado e a policy está certa?".

Próximo da série: #21 — Migrations SQL à mão e o drift DB↔Drizzle.