Chave de role de serviço Supabase exposta em JavaScript: o que significa e como encontrá-la

O que é a chave de role de serviço

O Supabase emite duas chaves distintas para cada projeto: a chave anon (também chamada de chave publicável em projetos mais novos) e a chave service_role. Ambas são JSON Web Tokens assinados pelo segredo JWT do seu projeto. A diferença é o claim role embutido no payload do JWT — anon para a chave pública, service_role para a chave mestra. PostgREST, Supabase Storage e Supabase Auth todos entram em modo de contornar-tudo quando veem o claim service_role.

Decodifique qualquer chave Supabase em jwt.io e olhe o payload. O formato de um JWT de role de serviço é inconfundível:

Payload decodificado de um JWT de role de serviço (mostrado como bloco destacado abaixo).

{
  "iss": "supabase",
  "ref": "[project-ref]",
  "role": "service_role",
  "iat": 1700000000,
  "exp": 2000000000
}

Projetos Supabase mais novos emitem chaves tipo segredo com o prefixo sb_secret_ em vez de JWT. O comportamento é idêntico — qualquer coisa carregando sb_secret_ em um bundle público é igualmente catastrófica.

Como ferramentas de codificação com IA vazam a chave de role de serviço

Vimos os mesmos três padrões em milhares de apps gerados por IA. Cada um começa com um desenvolvedor pedindo ajuda a uma ferramenta de IA e termina com a chave de serviço inline em um bundle.

Padrão 1: arquivo .env único com prefixo NEXT_PUBLIC_

O desenvolvedor pede à ferramenta de IA para "configurar o Supabase" e aceita um único .env com ambas as chaves. A ferramenta de IA — treinada em um corpus onde a maioria das variáveis de ambiente é exposta via NEXT_PUBLIC_* — prefixa ambas com NEXT_PUBLIC_. O Next.js incorpora qualquer coisa que corresponda a esse prefixo no bundle do cliente em tempo de build. Publique no Vercel, e a chave de serviço está em main.[hash].js.

Padrão 2: chave errada na chamada createClient

O desenvolvedor cola ambas as chaves em um arquivo config.ts que a IA gerou, e a IA popula erroneamente a chamada createClient() do lado do navegador com process.env.SUPABASE_SERVICE_ROLE_KEY. O build puxa a variável e o JWT vai parar no bundle.

Padrão 3: chave de role de serviço hardcoded em scripts de seed

O desenvolvedor pede à ferramenta de IA para escrever um script que popula o banco. A IA escreve a chave de role de serviço diretamente no arquivo (em vez de ler do ambiente), commita o arquivo no repositório, e o repositório público do GitHub ou a rota /scripts/seed.js do app publicado agora está servindo a chave.

Como o bundle scan do FixVibe detecta o vazamento

A verificação de segredos em bundle do FixVibe baixa cada arquivo JavaScript referenciado pelo app publicado — entry chunks, chunks lazy-loaded, web workers, service workers — e os passa por um detector que decodifica qualquer coisa correspondente ao formato JWT (eyJ[base64-header].eyJ[base64-payload].[signature]). Se o payload decodificado contém "role": "service_role", a varredura reporta como achado crítico com o caminho do arquivo e a linha exata onde a chave aparece. A mesma verificação também detecta o padrão mais novo sb_secret_* por prefixo.

A varredura nunca se autentica com a chave descoberta. Identifica o formato e reporta o vazamento — usar a chave para provar a explorabilidade seria acesso não autorizado ao seu banco de dados. A prova está no próprio payload do JWT.

Detectada — o que fazer na primeira hora

Uma chave de role de serviço vazada é uma emergência em produção. Assuma que a chave foi coletada — atacantes monitoram bundles públicos em tempo real. Trate o banco como comprometido até que tenha rotacionado a chave e auditado a atividade recente.

1. Rotacione a chave imediatamente. No painel do Supabase, vá para Configurações do Projeto → API → Service role key → Reset. A chave antiga é invalidada em segundos. Qualquer código do lado do servidor que use a chave deve ser atualizado e republicado antes da rotação se concretizar.
2. Audite a atividade recente do banco. Abra Database → Logs no painel. Filtre os últimos 7 dias. Procure consultas SELECT * incomuns contra tabelas com PII, declarações UPDATE ou DELETE grandes e requisições de IPs fora da sua infraestrutura conhecida. O Supabase registra o cabeçalho x-real-ip em cada requisição.
3. Verifique objetos de storage. Visite Storage → Logs e revise downloads recentes de arquivos. Uma chave de role de serviço vazada também dá acesso de contornar-tudo a buckets privados.
4. Remova a chave do controle de versão. Mesmo após a rotação, deixar o JWT no seu histórico git significa que ele é descobrível no repositório público. Use git filter-repo ou BFG Repo-Cleaner para limpá-lo do histórico, depois force-push (avise os colaboradores primeiro).
5. Varra de novo após a correção. Rode uma nova varredura do FixVibe contra o app republicado. O achado de segredos em bundle deve desaparecer. Confirme que nenhum JWT service_role e nenhuma string sb_secret_* permanece em nenhum chunk.

Prevenindo o vazamento desde o início

A correção estrutural é disciplina de nomenclatura mais guardrails em nível de ferramenta:

• Nunca prefixe a chave de serviço com NEXT_PUBLIC_*, VITE_* ou qualquer outro prefixo de incorporação em bundle. A convenção de nomenclatura é a fronteira — todo framework a respeita.
• Mantenha a chave de serviço fora do .env da máquina do desenvolvedor por completo. Leia-a de um gerenciador de segredos (Doppler, Infisical, variáveis de ambiente criptografadas do Vercel) no deploy, nunca a commite localmente.
• <strong>Mark every Supabase client construction with explicit context.</strong> Files named <code>supabase/browser.ts</code> use the anon key; files named <code>supabase/server.ts</code> use the service-role key with <code>import 'server-only'</code> at the top. The <code>server-only</code> import causes a build error if a client component tries to consume the module.
• <strong>Add a pre-commit hook that greps for JWT-shaped strings.</strong> <code>git diff --staged | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+'</code> catches both anon and service tokens before they leave your machine.
• Adicione um gate de CI que varra a saída do build. Após next build, faça grep da saída de .next/static/chunks/ pela string service_role. Faça o build falhar se algo corresponder.

# Pre-commit hook: refuse any staged JWT-shaped string.
git diff --staged \
  | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+' \
  && echo "JWT detected in staged changes — refusing commit" \
  && exit 1

# CI gate: fail the build if "service_role" shipped to the static bundle.
grep -RE 'service_role|sb_secret_' .next/static/chunks/ \
  && echo "Service-role credential leaked into bundle" \
  && exit 1

Perguntas frequentes

Próximos passos

Rode uma varredura do FixVibe contra sua URL de produção — a verificação de segredos em bundle é gratuita, sem cadastro, e reporta exposição de service_role em menos de um minuto. Combine com o artigo Scanner de RLS Supabase para verificar que a camada RLS está fazendo seu trabalho, e o Checklist de segurança de buckets Supabase Storage para bloquear o acesso a arquivos. Para o contexto sobre por que ferramentas de IA geram essa classe de vazamento com tanta confiabilidade, leia Por que ferramentas de codificação com IA deixam lacunas de segurança.