Pular para o conteúdo

Seu app do Bolt é seguro?

É seguro construir no Bolt? O código raramente é o problema. Quem decide é se as tabelas que o Bolt escreveu para você chegaram a ser trancadas.

Vlad Tkachenko5 min de leitura
O cartão de verificação de segurança da Reeve para apps do Bolt, com o logo do Bolt num ladrilho branco.

Os logotipos são propriedade de seus respectivos donos e são exibidos apenas para indicar compatibilidade.

Em resumo

  • Um app do Bolt costuma ser seguro do lado do código. Quem decide é se as tabelas que o Bolt gerou chegaram a ser trancadas.
  • Tabelas criadas rodando SQL não ganham Row Level Security por padrão, e escrever SQL é como o Bolt as cria.
  • Uma chave publicável no seu app está certa. sb_secret_… ou service_role chegando ao navegador é a que se troca hoje.

O Bolt escreve o projeto inteiro: as telas, as ligações e as tabelas de banco de dados por baixo. Essa última parte é a que você nunca vê, e é onde começa de verdade quase toda história de "meu app do Bolt está vazando dados".

Aqui está o que guia após guia erra: o código que o Bolt escreveu raramente é o problema. O problema costuma ser uma única chave por tabela no seu banco que nunca foi ligada, por causa de como as tabelas foram criadas e não porque alguém errou.

O que o Bolt entrega a um visitante e o que ele guarda

Duas metades, e só uma delas é privada.

Pense numa loja. O Bolt constrói para você uma vitrine (páginas, botões, formulários), e essa vitrine inteira é entregue a cada visitante que carrega o seu site. Tem que ser assim. Um navegador não exibe uma página que não recebeu, então não existe versão disso em que a frente do seu app seja secreta. Atrás dela fica um estoque, o seu banco no Supabase, um prédio separado com a própria fechadura.

A suposição que sai caro é que a vitrine comanda o estoque. Ela não comanda. O seu banco fica na internet com endereço próprio, e esse endereço está impresso na vitrine porque é assim que o seu próprio app chega até ele. Quem lê os seus arquivos publicados lê o endereço também, e daí consegue falar com o estoque sem nunca atravessar a sua loja.

É problema o meu app do Bolt ter uma chave de API dentro?

Normalmente não. Depende inteiramente de qual chave é, e existem duas que parecem quase idênticas.

As duas se chamam chave de API. Só uma delas foi feita para ser lida.

Uma chave publicável nomeia o seu projeto e nada além disso. O Supabase a chama de sb_publishable_… nos projetos novos e anon nos antigos, e ela foi feita para ficar num navegador, onde qualquer um pode ler. Uma chave secreta (sb_secret_…, ou service_role antes da renomeação) é o oposto. Ela ignora todas as regras que você escreveu e lê e escreve em toda linha de toda tabela.

As duas ficam lado a lado no painel do Supabase, têm tamanho parecido e se comportam igual enquanto você constrói. Nada quebra se a errada for copiada, e é exatamente por isso que ela sobrevive até a produção. A versão longa de como diferenciar leva cerca de um minuto de leitura.

A chave que decide a quem o seu banco responde

Row Level Security é uma configuração por tabela no Supabase que decide, linha a linha, quem pode ler o quê. Desligada, a sua chave publicável devolve a tabela inteira. Ligada, com uma política escrita, devolve só as linhas que a política permite.

O seu app e um estranho batem na mesma porta. A configuração decide quem entra, não as telas do seu app.

Agora a parte que vale especificamente para um projeto do Bolt. O Supabase liga o Row Level Security por padrão nas tabelas criadas no Table Editor do painel, aquele de clicar. Tabelas criadas rodando SQL não recebem isso e precisam ser ligadas de propósito.

O Bolt cria as suas tabelas escrevendo SQL.

Então o formato usual de um projeto do Bolt é um conjunto de tabelas geradas que chegaram destrancadas, ao lado do que você acrescentou na mão depois, que não. As duas são indistinguíveis no editor e as duas funcionam perfeitamente. E ligar a configuração também não é a linha de chegada: uma tabela com Row Level Security ligado e uma política que permite todo mundo está aberta enquanto se declara fechada.

Como conferir o seu próprio app do Bolt em uns dez minutos

Leia a sua lista de políticas. No Supabase, Authentication → Policies mostra cada tabela com o estado do Row Level Security. Comece por tudo que estiver marcado como desligado; isso pode ser lido por qualquer um que tenha o endereço do seu projeto.

Confirme qual chave você publicou. Settings → API no Supabase mostra as duas. A publicável dentro do seu app está certa e não precisa de nada. Se alguma vez colaram uma chave secreta no projeto, troque a chave lá antes de mexer no código: apagar a linha não fecha a porta, porque o valor antigo sobrevive em cópias em cache do seu site.

Confira os seus buckets de armazenamento. Um bucket marcado como público pode ser listado e baixado por qualquer um, com ou sem link do seu app para os arquivos dele.

E então olhe de fora. Tudo acima diz o que está configurado. Não diz o que um estranho realmente alcança, que é outra pergunta e é a que importa. O nosso scan gratuito lê o seu site no ar do jeito que qualquer visitante leria e te dá uma nota em uns 20 segundos, sem precisar de conta: escaneie seu app.

O que fazer

  • Tudo que o Bolt entrega a um navegador pode ser lido por qualquer um. É assim que navegadores funcionam, e esconder não é um caminho que valha a pena.
  • Uma chave publicável no seu app está certa. Uma chave secreta (sb_secret_… ou service_role) é a que se troca hoje.
  • Tabelas criadas rodando SQL não ganham Row Level Security por padrão, e escrever SQL é como o Bolt cria tabelas.
  • Ligar a configuração é o passo um. Uma política que permite todo mundo deixa a tabela aberta enquanto o painel a mostra como protegida.
  • O seu app funcionar não é prova de que ele está trancado. Por dentro, os dois estados parecem idênticos.

Abra Authentication → Policies no Supabase e leia a lista de cima a baixo. Se alguma coisa ali disser que o Row Level Security está desligado, é por essa tabela que se começa, e o checklist de segurança de 10 minutos cobre o resto da superfície depois disso.

O que pode dar errado de verdade com um app do Bolt

Nada disso significa que você fez algo errado: são os efeitos colaterais habituais de construir rápido. Aqui está o que vale a conferida:

  • Uma chave secreta indo parar no navegador (a armadilha VITE_)

    Apps do Bolt geralmente são construídos com Vite, que tem uma regra que pega as pessoas: qualquer configuração cujo nome começa com VITE_ é embutida no código que roda no navegador do seu visitante, onde qualquer um pode ler. Nomeie um segredo de verdade como VITE_ALGUMACOISA e ele vai a público. Algumas chaves devem ser públicas (como uma chave “anon” do Supabase), o que está ok: o Reeve distingue as seguras das perigosas, então sem alarmes falsos.

  • Seu banco de dados deixado aberto (RLS do Supabase desligado)

    O Bolt costuma conectar seu app ao Supabase para os dados. O Supabase tem uma chave chamada Row Level Security (RLS) que decide quem pode ler ou alterar cada linha. Se estiver desligada, suas tabelas podem ser legíveis, ou editáveis, por qualquer um que encontrar o endereço. É o problema sério mais comum em apps feitos por IA, e é invisível a menos que você verifique.

  • Um arquivo .env ou de configuração exposto

    O arquivo .env guarda as chaves e senhas de um projeto. Às vezes é publicado por acidente junto com o app implantado. Se estiver acessível por fora, é um atalho para tudo o que é sensível. O Reeve verifica se o seu está acessível sem você saber.

  • Armazenamento de arquivos público

    Se as pessoas enviam arquivos ao seu app, eles vivem em “buckets” de armazenamento. Um bucket deixado público significa que qualquer um pode listar ou baixar o que há dentro, então um envio privado pode acabar visível para todos. O Reeve verifica se os seus buckets são listáveis; ele nunca baixa os arquivos de ninguém.

  • Source maps deixados ligados

    Um “source map” é um arquivo de apoio que revela o código original do seu app. Útil durante o desenvolvimento, mas se for para produção entrega a estranhos um mapa legível de como o seu app funciona, deixando cada outra porta mais fácil de achar. Baixa urgência, mas vale organizar.

  • Cabeçalhos de segurança ausentes e endpoints abertos

    Pequenas configurações que dizem aos navegadores como proteger seus visitantes, além de se os seus endpoints de dados respondem a qualquer um ou a qualquer site. Pequenos sozinhos; juntos, ampliam a brecha. O Reeve sinaliza os que estão faltando.

O que o Reeve é, e o que não é

O Reeve é uma verificação gratuita, somente leitura e por fora, como um inspetor que dá a volta no prédio e testa as portas. É 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.

O Bolt e o StackBlitz seguem melhorando o que é gerado, e se o seu app usa Supabase, o próprio consultor do Supabase sinaliza problemas de banco de dados no painel. Ambos ajudam. O que o Reeve acrescenta: você vive no Bolt, não em um painel, e essas ferramentas falam em linguagem de desenvolvedor. O Reeve olha o seu app implantado inteiro por fora, do jeito que um estranho faria, e diz o que encontra em palavras com as quais você pode agir. E se você preferir não pensar nisso, podemos monitorar para você.

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 Care

Perguntas frequentes

Meu app do Bolt é seguro por padrão?

O Bolt te dá rápido um app que funciona, mas “seguro por padrão” depende de como ele está ligado, especialmente das suas variáveis de ambiente e, se você usa Supabase, das regras do seu banco de dados. A única forma de saber é verificar o que está de fato exposto, e é isso que o Reeve faz de graça em cerca de 20 segundos.

Por que minha chave de API vazou em um app do Bolt?

Normalmente porque estava guardada em uma configuração começando com VITE_. O Vite embute essas de propósito no bundle do navegador, então qualquer segredo com esse nome fica público. O Reeve lê o código carregado do seu app, encontra as chaves e diz quais são seguras de expor e quais precisam ir para o servidor.

O Bolt usa Supabase, e isso é seguro?

O Bolt conecta apps ao Supabase com frequência. O Supabase é seguro quando o Row Level Security está ligado e só a sua chave pública “anon” está no front-end. Se o RLS estiver desligado ou uma chave “service_role” vazar, seus dados podem ser expostos. O Reeve verifica os dois sem nunca ler seus dados reais.

Verificar meu app do Bolt vai mudar algo?

Não. O Reeve só olha o que já é público por fora. Ele nunca faz login, nunca muda nada e nunca baixa seus arquivos. Somente leitura, como conferir se uma porta está trancada sem entrar.

O Bolt escreveu as minhas tabelas. Elas vêm trancadas por padrão?

Muitas vezes não, e o motivo é mecânico. O Supabase liga o Row Level Security automaticamente nas tabelas que você cria clicando no Table Editor, mas não nas criadas rodando SQL. Um builder cria tabelas rodando SQL, então essas tabelas chegam com a chave desligada, a menos que alguma coisa a tenha ligado depois.

A pré-visualização funcionava e o app publicado funciona. Isso quer dizer que está configurado certo?

Não, porque os dois funcionariam de qualquer jeito. Um app sem regras no banco se comporta exatamente como um app com as regras certas, até o momento em que alguém consulta o banco direto em vez de passar pelas suas telas. Funcionar não é o mesmo teste que estar protegido.

Onde eu olho para saber se o meu projeto do Bolt tem esse problema?

Abra o seu projeto no Supabase e vá em Authentication, depois Policies. Cada tabela do schema public aparece ali com o estado do Row Level Security. Qualquer tabela marcada como desligada pode ser lida por quem tiver o endereço do seu projeto e a sua chave publicável, e as duas coisas estão dentro do app que você publicou.

Escrito por

Vlad Tkachenko

Fundador da Reeve

Passo meus dias olhando apps criados com Lovable, Bolt, v0, Cursor e Replit, e a curta lista de erros que aparecem neles sem parar.

Mais sobre o autor

Criou em outro lugar? Temos o mesmo resumo honesto para:

← Ver todos os guias de segurança dos criadores

Verificação externa automatizada, não uma auditoria completa. A ausência de achados não é garantia de segurança.