Reeve Seu app do Supabase é seguro?
O Supabase é o banco de dados e o backend por trás de uma enorme fatia dos apps feitos com vibe coding. É poderoso e seguro quando está bem configurado — mas algumas poucas configurações decidem se seus dados são privados ou abertos ao mundo, e elas são fáceis de passar batido.
O Reeve verifica as que importam por fora, de graça, e explica o que encontra em linguagem simples. Sem instalação, sem acesso ao seu projeto — só olhamos o que já está acessível, e nunca lemos seus dados reais.
Cole o link do seu app. Cerca de 20 segundos. Veja sua nota sem cadastro.
O que pode dar errado de verdade com o Supabase
Nada disso significa que você fez algo errado — são as brechas habituais quando se está indo rápido. Aqui está o que vale a conferida:
Row Level Security (RLS) desligada
O RLS é a regra do Supabase sobre quem pode ler ou alterar cada linha de uma tabela. Com a chave pública “anon” — que deve estar no seu app — qualquer um pode consultar seu banco de dados diretamente. O RLS é o que o impede de ver linhas que não são dele. Se estiver desligada, uma tabela pode ser totalmente legível, ou até editável, por qualquer um. É a configuração mais importante do Supabase, e o Reeve a verifica contando linhas, nunca lendo-as.
Uma chave service_role vazada
O Supabase te dá duas chaves. A chave “anon” é pública por design e segura no navegador. A chave “service_role” ignora todas as suas regras de segurança e deve viver apenas em um servidor. Se ela algum dia acabar no código do front-end do seu app, alguém pode fazer qualquer coisa com seus dados. O Reeve decodifica as chaves que encontra e diz exatamente qual está exposta — a “anon” segura recebe um tique verde, a “service_role” é um alerta vermelho.
Buckets de armazenamento públicos
Os arquivos que as pessoas enviam vivem em “buckets” do Supabase Storage. Um bucket definido como público significa que qualquer um pode listar e baixar o que há dentro — então envios privados podem se tornar visíveis para todos. O Reeve verifica se os seus buckets são listáveis; ele nunca baixa os arquivos de ninguém.
Sua API aberta a qualquer site (CORS)
O Supabase dá ao seu banco de dados um endereço web (via PostgREST). Combinado com uma configuração de compartilhamento permissiva demais, outro site poderia chamar seus dados a partir do navegador de um visitante. O Reeve verifica se os seus endpoints respondem a estranhos e a outros sites — sem nunca usá-los para mudar nada.
Tabelas e endpoints expostos sem regras
Cada tabela que você cria é acessível pela API do Supabase — isso é por design, e o RLS deve protegê-la. Mas uma tabela nova adicionada com pressa, antes de suas regras serem definidas, pode ficar brevemente (ou de forma duradoura) aberta. O Reeve verifica o que está de fato acessível por fora.
Chaves ou configuração deixadas no app implantado
Além das próprias chaves do Supabase, os apps muitas vezes carregam outras configurações e segredos no código front-end ou em um .env exposto. O Reeve lê o código carregado do seu app e verifica se há arquivos de configuração acessíveis, depois diz quais valores são seguros de tornar públicos e quais não são.
O que o Reeve é — e o que não é
O Reeve é uma verificação gratuita, somente leitura e por fora — como um inspetor que testa as portas sem entrar. É rápida e pega os erros comuns de grande impacto. Não é uma auditoria de segurança completa, e uma nota limpa não é garantia — significa que as portas óbvias estão fechadas. Tudo o que o Reeve faz é passivo: ele conta linhas em vez de lê-las, e nunca baixa seus arquivos.
O Supabase te dá ferramentas de segurança reais — um Security Advisor e um linter de banco de dados que sinalizam problemas de RLS e de exposição bem no painel — e vale muito a pena usá-los. O que o Reeve acrescenta: a maioria de quem constrói no Supabase vive no seu criador de apps, não no editor SQL, e o advisor fala em linguagem de desenvolvedor. O Reeve verifica o seu app inteiro por fora — do jeito que um invasor chegaria aos seus dados — e explica o que encontra em palavras simples. E se você preferir não monitorar você mesmo, nós podemos.
Quer que seja resolvido, não só verificado?
O Reeve Care continua monitorando seu app, faz backup dos seus dados e ajuda você a corrigir as coisas quando quebram — para que você siga criando em vez de se preocupar.
Conheça o Reeve CarePerguntas, respondidas com honestidade
O que é o RLS do Supabase e eu realmente preciso dele?
O RLS (Row Level Security) decide quem pode ver ou alterar cada linha das suas tabelas. Como o seu app envia uma chave pública “anon” capaz de consultar o banco de dados diretamente, o RLS é o que impede que os dados de um usuário fiquem visíveis para todos. Sim — para qualquer tabela com dados reais, você precisa dele ligado. O Reeve verifica se está, sem ler seus dados.
A chave anon do Supabase é segura de expor?
Sim — a chave “anon” foi feita para viver no seu front-end, e sozinha ela só faz o que suas regras de RLS permitem. A chave que nunca deve ser exposta é a “service_role”, que ignora todas as regras. O Reeve decodifica as chaves do seu app e diz qual é qual.
O que acontece se a minha chave service_role vazar?
A chave service_role ignora todas as regras de segurança, então quem a tiver pode ler, alterar ou apagar todos os seus dados. Se ela está no seu código front-end, trate-a como comprometida: rotacione-a no painel do Supabase e mova-a para um servidor. O Reeve sinaliza uma chave service_role exposta como um problema crítico.
O Reeve pode verificar meu Supabase sem a senha do meu banco de dados?
Sim. O Reeve só usa o que o seu app já expõe publicamente — a mesma chave anon e os mesmos endpoints que o navegador de qualquer visitante usa. Ele nunca precisa da senha do seu banco de dados, nunca faz login como administrador e nunca lê nem baixa suas linhas ou arquivos.
Criou seu app em uma ferramenta específica? Aqui está o mesmo resumo honesto para:
Verificação externa automatizada, não uma auditoria completa. A ausência de achados não é garantia de segurança.