Regras de acesso no Supabase e no Firebase (CWE-862): como a falta de Row Level Security expõe dados e como corrigir

Conceitos Centrais e Termos

Chave anon pública

A chave anon do Supabase e a configuração web do Firebase vão dentro do pacote do app, e qualquer pessoa pode copiá-las. Elas identificam o projeto, não o usuário, então não são segredo e não protegem dados sozinhas.

Row Level Security (RLS)

Um recurso do PostgreSQL que filtra toda consulta por meio de políticas. O Table Editor do Supabase a ativa em tabelas novas, mas tabelas criadas com SQL ou migrações começam com RLS desligada, e as permissões padrão deixam anon e authenticated ler e alterar todas as linhas.

USING e WITH CHECK

USING define quais linhas existentes um usuário pode ver, atualizar ou apagar; WITH CHECK define quais linhas novas ou alteradas ele pode gravar. Uma política só com USING em insert ou update deixa usuários gravarem linhas para outra organização.

Chave service_role

A chave service_role ignora a RLS por completo. Ela só deve ficar em servidores e edge functions, nunca num navegador ou app mobile.

Regras do Firestore em modo de teste

Projetos iniciados em modo de teste recebem regras que liberam leitura e escrita até uma data, e muitos depois viram allow read, write: if true. As regras precisam comparar request.auth.uid com o campo de dono do documento.

Fluxo de Ataque Passo a Paso

Código-Fonte: Vulnerável vs. Seguro

-- migration.sql: a RLS nunca é ativada nesta tabela
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- a chave anon pública pode ler, alterar e apagar todas as linhas
grant select, insert, update, delete on public.invoices to anon, authenticated;

-- migration.sql: RLS ligada, anon revogado, uma política por comando
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- com a RLS ligada, sem política não há acesso
alter table public.invoices enable row level security;
revoke all on public.invoices from anon;

-- usuários veem só faturas das organizações a que pertencem
create policy "members read their org's invoices"
  on public.invoices for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

-- linhas novas precisam ser de uma organização do usuário; sem política de update ou delete
create policy "members add invoices to their org"
  on public.invoices for insert to authenticated
  with check (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

Lista de Verificação de Segurança para Engenharia

• Ative a RLS em toda tabela de schemas expostos e falhe o CI quando select tablename from pg_tables where schemaname = 'public' and not rowsecurity devolver alguma linha.
• Escreva uma política por comando, restrita to authenticated, com USING para leituras e WITH CHECK para inserts e updates; deixe de fora políticas de update e delete que não forem necessárias.
• Revogue as permissões da tabela para anon quando usuários anônimos não tiverem motivo para ler, e mantenha a chave service_role só em ambientes de servidor.
• Ative a RLS nas tabelas lidas pelas suas políticas, como memberships, para que usuários não se adicionem a outra organização.
• Teste com dois usuários de teste: o usuário A deve receber zero linhas da organização do usuário B; no Firestore, rode testes de regras no emulador com @firebase/rules-unit-testing.

Fontes

• CWE-862: Missing Authorization
• Supabase docs — Row Level Security
• PostgreSQL docs — CREATE POLICY
• Firebase docs — Get started with Cloud Firestore Security Rules
• NVD — CVE-2025-48757 (missing Row Level Security in generated apps)