A ronda flagra. Sua Missão, o plano de conserto desta ronda, mostra o que fechar primeiro.
O nível de exposição do seu app e cada brecha que a ronda encontrou.
0 = tranquilo · 100 = muito exposto — quanto menor, melhor
Resolva 2 itens críticos e a exposição cai para ~20 (Baixo).
│ = seu app agora (78). Faixas: seguro (0–14) · baixo (15–39) · médio (40–69) · alto (70–100).
A ronda soma a gravidade de cada achado — críticos pesam muito mais. O número fica na faixa do pior achado em aberto. Consertar (e confirmar numa nova ronda) é o que derruba.
O medidor nunca chega a 0: nenhum app tem risco zero, e a Guarita não promete o que não pode medir.
Revisamos seu app inteirinho e a notícia é boa: dá pra ficar tranquilo rápido. Você já acertou em várias coisas — HTTPS, certificado e e-mail estão certos.
O que precisa de atenção agora são 2 brechas críticas: uma chave de administrador exposta e a proteção dos dados desligada. Juntas, elas deixam qualquer visitante ler e mudar os dados dos seus usuários. Parece assustador, mas o conserto é simples e está tudo explicado abaixo, com um prompt pronto pra colar na sua IA.
Quando os 2 itens críticos estiverem resolvidos, seu nível de exposição cai de Alto para Baixo.
Conclua os Objetivos da Missão abaixo pra ver sua exposição estimada cair em tempo real.
Já priorizamos por você: o mais grave vem primeiro.
Sem jargão. Cada achado explica o que é, por que importa e traz o conserto pronto pra colar na sua IA.
A service_role é a chave de administrador do seu Supabase. Ela está escrita no JavaScript que qualquer visitante baixa só de abrir seu site.
o começo da chave que encontramos no seu código, encurtado por segurança
eyJhbGciOiJIUzI1Ni… · role: "service_role" · exp: 2077428374 · fonte: app.exemplo.com.br/assets/index-CBWCsxTw.js
Com ela, qualquer pessoa pode ler, alterar ou apagar todos os dados do seu app — usuários, pedidos, tudo. É o acesso mais perigoso que existe.
Por que acontece — Costuma acontecer quando a chave de servidor é usada no código do front por engano — ferramentas de IA fazem isso sem avisar.
O que fazer AGORA, grátis: revogue ou rotacione essa chave no painel do provedor — corta o acesso na hora.
Cole no chat da ferramenta que você já usa (Claude Code, Cursor, Lovable…) e a IA corrige pra você.
Minha aplicação está expondo a chave service_role do Supabase no front-end — uma falha CRÍTICA de segurança. Por favor: 1. Remova todo uso da service_role (SUPABASE_SERVICE_ROLE_KEY) do código do cliente/front-end. 2. No front, ao criar o cliente Supabase, use SOMENTE a chave anon (SUPABASE_ANON_KEY). 3. Se alguma ação precisa de privilégio de admin, mova-a para uma Edge Function / rota de servidor, com a service_role guardada como variável de ambiente secreta (nunca enviada ao navegador). Ao terminar, liste onde a service_role aparecia e o que você alterou.
eyJhbGciOiJIUzI1Ni… · role: "service_role" · exp: 2077428374 · fonte: app.exemplo.com.br/assets/index-CBWCsxTw.js
A “proteção por linha” (RLS) da sua tabela users está desligada. Sem ela, a regra vale pra todo mundo: qualquer um vê tudo.
a resposta que o seu banco devolveu ao nosso teste sem login
GET /rest/v1/users?select=* → 200 OK · 1.482 linhas retornadas
Hoje alguém consegue baixar a lista inteira de e-mails e dados dos seus 1.482 usuários sem nem fazer login.
Por que acontece — As ferramentas criam as tabelas, mas ligar o RLS fica por sua conta — e esse passo passa batido com frequência.
Cole no chat da ferramenta que você já usa (Claude Code, Cursor, Lovable…) e a IA corrige pra você.
A tabela "users" do meu Supabase está com Row Level Security (RLS) DESATIVADO, deixando os dados de todos os usuários acessíveis publicamente. Por favor: 1. Ative o RLS na tabela users. 2. Crie políticas para que cada usuário acesse apenas os próprios registros (auth.uid() = id) em select, update e delete. 3. Revise as demais tabelas com dados de usuário e ative RLS + políticas equivalentes onde faltar. Gere o SQL de migração e explique em uma frase o que cada política faz.
GET /rest/v1/users?select=* → 200 OK · 1.482 linhas retornadas
Sua API aceita pedidos de qualquer site (o “CORS” está liberado pra todos com *).
as permissões de origem que a sua API devolveu ao nosso teste
https://app.exemplo.com.br/rest/v1/ · Origin: https://evil.test → Access-Control-Allow-Origin: https://evil.test
Um site malicioso pode usar a sessão de quem está logado no seu app pra fazer ações em nome da pessoa (roubo de sessão).
Cole no chat da ferramenta que você já usa (Claude Code, Cursor, Lovable…) e a IA corrige pra você.
Minha API/Supabase aceita requisições de qualquer origem (CORS liberado com "*"), o que permite roubo de sessão. Por favor: 1. Restrinja o CORS para aceitar SOMENTE o meu domínio de produção (https://app.exemplo.com.br) e o localhost de desenvolvimento. 2. Atualize a configuração de Allowed Origins / o header Access-Control-Allow-Origin — nunca use "*". 3. No Supabase, ajuste as URLs permitidas em Auth - URL Configuration. Diga o que foi alterado.
https://app.exemplo.com.br/rest/v1/ · Origin: https://evil.test → Access-Control-Allow-Origin: https://evil.test
Seu site não tem uma Content-Security-Policy — uma regra que bloqueia scripts não autorizados de rodarem na página.
o que a resposta do seu site mostrou (ou deixou de mostrar) nesse cabeçalho
GET https://app.exemplo.com.br/ → resposta sem o header Content-Security-Policy
O cookie de sessão não tem as marcas Secure e SameSite, que o protegem em trânsito.
o cookie como o navegador o recebe — dá pra ver as marcações que faltam
Set-Cookie em https://app.exemplo.com.br/ → session=…; HttpOnly (sem Secure, sem SameSite)
Bom trabalho, comandante. Mantenha assim. 🛡️
A ronda básica é grátis e ilimitada. Em segundos você vê o que está exposto.
Rodar no meu app →