O SUPABASE É SEGURO? ANÁLISE DE SEGURANÇA 2026 | VIBEEVAL

RLS não é negociável

O Supabase expõe seu banco PostgreSQL diretamente aos clientes via anon key. Sem políticas de RLS, qualquer pessoa com a URL do seu projeto consegue ler, modificar ou deletar todos os dados nas tabelas desprotegidas. Isso não é um bug — é o modelo de dados. O Supabase foi desenhado para que o banco seja a camada de autorização; se você quebra esse modelo deixando RLS desativado, não existe segunda linha de defesa.

O modelo mental chave: a anon key não é “a chave que só lê” — é a chave que pode fazer exatamente o que suas políticas permitirem. Sem políticas, “tudo é permitido”.

Problemas de segurança comuns

Políticas de RLS ausentes

Tabelas sem RLS ativo ficam totalmente acessíveis para qualquer um com a anon key, levando à exposição completa dos dados. Qualquer um que carrega seu frontend vê a URL do Supabase e a anon key na aba Network do DevTools — assim que tem isso, pode chamar https://<project>.supabase.co/rest/v1/<table>?select=* direto com curl.

Habilite RLS por tabela e escreva pelo menos uma política:

alter table profiles enable row level security;

create policy "users read own profile"
  on profiles for select
  using ( auth.uid() = user_id );

create policy "users update own profile"
  on profiles for update
  using ( auth.uid() = user_id )
  with check ( auth.uid() = user_id );

Sem with check em update/insert, um usuário pode modificar uma linha de modo que, depois do update, ela pertença a outra user_id.

Vazamento da service role key

A service_role key ignora RLS. Expô-la no código do client dá acesso total ao banco para atacantes. Os caminhos de vazamento mais comuns que vemos: em uma env var NEXT_PUBLIC_* do Next.js (tudo com esse prefixo vai pro bundle), em um repo público do GitHub sob .env.example com valor real, ou em uma env var de preview do Vercel mal escopada para o ambiente errado.

Separe estritamente: a service role key vive só em código de servidor (Edge Functions, API routes sem prefixo NEXT_PUBLIC_, workers de backend). Se você precisa dela no navegador, você não precisa dela — você precisa de uma política RLS melhor.

Políticas de RLS com falhas

Políticas de RLS com erros lógicos criam caminhos de acesso não intencionais. Políticas complexas exigem testes minuciosos. Armadilhas clássicas: definir uma política só em select e esquecer que update e delete também precisam de uma; usar em uma cláusula using um subquery em outra tabela sem RLS; ou colocar true como placeholder e nunca voltar para o check real.

Escreva testes pgTAP por política e rode no CI — RLS sem testes é esperança, não proteção.

Má configuração de Storage buckets

O Supabase Storage também requer RLS. Buckets públicos podem expor arquivos sensíveis. Em uploads, valide MIME por allowlist e ponha limite de tamanho; senão seu bucket vira CDN grátis para conteúdo de terceiros.

create policy "users read own files"
  on storage.objects for select
  using ( bucket_id = 'avatars' and auth.uid()::text = (storage.foldername(name))[1] );

Edge Functions sem checagem de auth

Edge Functions no Supabase rodam com a service role key se você não configura explicitamente de outro jeito. Uma Function que aceita uma request e executa uma operação no banco sem verificar o JWT que chegou é, efetivamente, um endpoint aberto que ignora RLS. Sempre verifique req.headers.get('Authorization') e use o token do usuário para o call ao banco em vez da service role key.

Realtime e postgres-changes

O Supabase Realtime respeita RLS para subscriptions postgres_changes, mas só se você ativar. Uma subscription numa tabela sem RLS transmite cada mudança para cada client conectado.

Avaliação de segurança

Pontos fortes

• • PostgreSQL com segurança de nível enterprise
• • Row Level Security (RLS) para controle granular de acesso
• • Autenticação embutida com tokens JWT
• • Código aberto — auditável em termos de segurança
• • Conformidade SOC 2 Type II

Preocupações

• • Políticas de RLS frequentemente ausentes ou mal configuradas
• • Configurações padrão podem expor dados
• • Anon key vai para o client — RLS é essencial
• • Vazamento da service role key concede acesso total
• • Sintaxe complexa de RLS leva a brechas de segurança

Aspectos enterprise

O Supabase oferece, nos planos Pro e Team, SSO (SAML), audit logs para ações do dashboard e bancos branch para ambientes de preview isolados. Se você atua em contexto regulado, três pontos são especialmente relevantes:

• Fronteira SOC 2: O Supabase é SOC 2 Type II compliant, mas a conformidade vale para a plataforma — não para as políticas que você escreve. Uma política RLS ausente é finding seu na auditoria, não do Supabase.
• Audit logs: Ative os audit logs e mande pra S3 ou Datadog. Sem logs off-site você não tem evidência, num incidente, de quem rotacionou a service role key ou removeu uma política.
• Branch DBs para PRs: Use branching em vez de copiar dados de produção para ambientes de preview. Uma URL de preview vazada com dados reais de usuários é um incidente de privacidade.

O veredito

O Supabase é seguro como plataforma, com a segurança testada do PostgreSQL. O fator crítico é a configuração correta de RLS. Habilite RLS em cada tabela, escreva e teste as políticas minuciosamente e nunca exponha a service_role key no código do client. Com configuração correta, o Supabase oferece excelente segurança.

Três checagens antes de cada launch: (1) select * from pg_tables where rowsecurity = false and schemaname = 'public' — lista vazia? Bom. (2) Faça grep no bundle do frontend procurando service_role e qualquer key que não seja a anon key. (3) Tente, como segundo usuário de teste, ler dados do primeiro. Se algo passa, sua política está errada.

Recursos relacionados

Como proteger o Supabase

Guia passo a passo de segurança com padrões de RLS, validação de JWT e hardening de Storage.

Checklist de segurança do Supabase

Checklist de segurança interativo — de “RLS em cada tabela” até “audit logs ativados”.

Supabase RLS Checker

Scan automatizado que verifica que cada tabela do seu projeto tem RLS ativo e pelo menos uma política.

Token Leak Checker

Acha service role keys, anon keys e secrets JWT vazados no seu bundle de frontend e nos seus repos.

Riscos de segurança de vibe coding

Visão geral dos padrões de falha que código gerado por IA introduz tipicamente em projetos Supabase.

Escaneie seu app Supabase

Deixe o VibeEval checar sua aplicação Supabase em busca de má configuração de RLS e vulnerabilidades — tabelas sem políticas, keys vazadas, buckets de Storage públicos, BOLA em Edge Functions. Resultados em menos de 60 segundos, com arquivo e número de linha pra corrigir.