// Segurança por ferramenta
Segurança para apps feitos no Bolt.new
Resposta rápida
O Bolt.new é frontend-first, e é isso que cria o furo mais comum: chave de API e credencial de provedor pago acabam escritas no código do client. Qualquer pessoa que abre o DevTools lê essa chave, e scraper automático acha chave exposta em deploy novo em questão de horas. Some a isso a service_role do Supabase (que ignora RLS) caindo no bundle e você tem acesso total ao banco vazando na tela.
Os quatro buracos que aparecem em quase todo app Bolt: service_role exposta, RLS ausente, XSS por input não escapado, e auth que existe na tela mas não verifica no servidor. Se subiu no Bolt e chama API paga ou tem login, revise antes de mandar pro cliente.
O que o Bolt costuma gerar errado
O output do Bolt puxa muita lógica pro browser: chamada direta do browser pro provedor, função sem proteção, sem rate limit, CORS fraco. Cada uma dessas vira porta aberta quando o app sai do protótipo e recebe usuário de verdade.
| Furo | Por que acontece | Impacto |
|---|---|---|
| service_role no bundle | Chave que ignora RLS escrita no client | Acesso total de leitura/escrita ao banco |
| Chave de API no client | Chamada browser→provedor com credencial embutida | Chave roubada por scraper em horas |
| XSS por input não escapado | Conteúdo do usuário renderizado sem sanitização | Sequestro de sessão / injeção de script |
| Sem rate limit no form handler | Endpoint aberto sem limite de requisição | Abuso, spam e custo de provedor |
Como a RET revisa um app feito no Bolt
A RET começa pelo que o browser carrega: abre o bundle e caça chave, service_role e endpoint que fala direto com provedor. Depois testa o que a auth realmente barra no servidor (não só na tela) e onde o input do usuário chega sem escape. Cada achado sai com reprodução e prioridade.
Pra primeira passada sozinho, o Promptbook tem prompt específico pra varrer chave no client, checar RLS e testar o handler. Sinal sério vai pro Risk Review.
- Varredura do bundle client atrás de chave e service_role.
- Teste de auth no servidor, não só no componente.
- Checagem de escape de input, rate limit e CORS.
Você já pode estar exposto se
Sinais que pedem revisão imediata num app Bolt:
- Seu app chama uma API paga (OpenAI, Stripe, etc.) direto do browser.
- Você usa Supabase e não sabe se a service_role vazou pro front.
- Você renderiza texto do usuário sem sanitizar.
- Seu form/endpoint não tem limite de requisição.
Perguntas frequentes
Por que a chave no client é tão grave no Bolt?
Porque o Bolt é frontend-first e tende a colocar a chamada no browser. Tudo que está no bundle é público: scraper automático varre deploys novos e acha chave exposta em horas, e aí o custo (e o acesso) é seu. A correção é mover a chave pra variável de ambiente e uma função no servidor.
Qual a diferença entre anon_key e service_role?
A anon_key é pública e respeita RLS. A service_role ignora RLS por completo, é chave de administração. Se a service_role cair no bundle do Bolt, qualquer um lê e escreve no banco inteiro. Ela nunca pode estar no client.
O Bolt não protege isso sozinho?
Não por padrão. Ele otimiza pra velocidade de protótipo, não pra postura de produção. A camada de servidor, o escape de input e o rate limit são passos que você (ou uma revisão) precisa adicionar antes de receber usuário real.
Quem faz a revisão na RET?
Gabriel Lima Ferreira, founder e lead pentester, com autorização e escopo fechado, entregando evidência reproduzível.