Checklist de segurança do Supabase RLS para apps criados com IA

Qualquer tabela no schema public exposta pela Data API é legível pela internet quando o RLS está desligado. Comece listando o que está exposto e ligue o RLS.

alter table public.leads enable row level security;

-- auditoria: tabelas públicas sem RLS
select tablename
from pg_tables t
where schemaname = 'public'
  and not exists (
    select 1 from pg_class c
    where c.relname = t.tablename and c.relrowsecurity
  );

RLS ligado sem nenhuma policy bloqueia tudo — isso é seguro. O perigoso é o contrário: policy larga com RLS ligado dá falsa sensação de proteção.

A armadilha mais comum. O assistente cria uma policy que “resolve o erro de permissão” e libera a tabela inteira:

-- vulnerável: qualquer visitante lê todos os leads
create policy "leads_select" on public.leads
for select using (true);

-- corrigido: apenas o dono da linha
create policy "leads_select_own" on public.leads
for select to authenticated
using (auth.uid() = user_id);

Regra prática: toda policy de select, update e delete deve referenciar auth.uid() ou uma função de papel. Se não referencia nada, é candidata a vazamento.

RLS e privilégios são coisas diferentes. Sem grant, o PostgREST devolve erro de permissão; com grant amplo demais e policy fraca, você entrega a tabela. Conceda o mínimo por papel.

grant select, insert, update, delete on public.leads to authenticated;
grant all on public.leads to service_role;
-- grant select ... to anon;  -- apenas se houver policy pública de leitura

Guardar role em profiles permite que o próprio usuário se promova a admin via update. Papéis vivem em tabela separada, lidos por função security definer.

create table public.user_roles (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) on delete cascade not null,
  role app_role not null,
  unique (user_id, role)
);

create or replace function public.has_role(_user_id uuid, _role app_role)
returns boolean language sql stable security definer set search_path = public
as $$ select exists (select 1 from public.user_roles
  where user_id = _user_id and role = _role) $$;

create policy "admins_read_leads" on public.leads
for select to authenticated using (public.has_role(auth.uid(), 'admin'));

A service role key ignora RLS por definição. Ela só pode existir em código de servidor. Procure por ela em variáveis VITE_*, em componentes React, em repositórios públicos e em logs — é onde ela costuma aparecer em projetos gerados por IA. Chaves anon / publishable são públicas por design e podem ficar no bundle, desde que o RLS esteja correto.

Policy não revisada é policy não testada. Use o cliente com a chave pública e tente ler dados de outro usuário; depois repita autenticado com uma conta comum.

-- simule um usuário específico no SQL editor
set local role authenticated;
set local request.jwt.claims = '{"sub":"<uuid-de-outro-usuario>"}';
select * from public.leads;  -- deve voltar vazio

Repita para insert, update e delete: muita aplicação protege a leitura e esquece que qualquer visitante pode apagar linhas.

Buckets públicos, funções de borda sem verificação de sessão e canais realtime abertos expõem os mesmos dados que a policy da tabela protegia. Revise: bucket público só para asset realmente público, função de servidor validando o token antes de tocar em dados, e publicação realtime restrita às tabelas necessárias.

• RLS habilitado em todas as tabelas do schema público
• Nenhuma policy com using (true) em dados privados
• GRANTs mínimos por papel (anon só onde há leitura pública)
• Papéis em tabela dedicada + função security definer
• Service role key ausente do bundle e dos logs
• Policies testadas com JWT de outro usuário, nos quatro verbos
• Storage, funções de servidor e realtime revisados junto