Reeve Noções de segurança
Scanner de segurança para vibe coding: o que ele não vê
Um scanner de segurança para vibe coding lê seu app no ar, de fora. O que isso cobre, as quatro coisas que ele não consegue ver e como ler o resultado.
Em resumo
- Um scanner de segurança para vibe coding lê o que os navegadores dos seus visitantes já baixam: seu bundle, seus cabeçalhos, seu certificado e as respostas que seu banco de dados dá a um desconhecido.
- Isso cobre justamente a classe de erros mais comum quando se constrói com IA. Não cobre nada do que acontece no seu servidor.
- Um resultado limpo significa que toda pergunta que a varredura conseguiu fazer de fora voltou limpa. Encare como uma preocupação a menos.
Você cola o endereço do seu app num scanner, espera uns vinte segundos e volta uma letra. A, talvez C. Aí chega a pergunta que realmente importa: isso quer dizer que meu app está bem?
Aqui está a parte que a maioria das ferramentas dessa categoria deixa para você descobrir sozinho. Um scanner de segurança para vibe coding lê seu app da rua. Ele vê o que o navegador de qualquer visitante vê, que é bastante coisa, e para na sua porta da frente. O que seu servidor faz em particular continua particular para ele também.
Saber onde essa linha passa é o que faz uma varredura valer a pena. Um A diz que as portas voltadas para a rua estavam fechadas quando olhamos, e não diz nada a respeito do cômodo lá atrás.
O que é um scanner de segurança para vibe coding?
Uma ferramenta que carrega seu app no ar como um visitante faria e depois lê o que voltou.
Você dá uma URL a ela. Ela não pede seu código-fonte, seu repositório, a senha do seu banco de dados nem uma conta no builder que você usou. Ela busca sua página, deixa o JavaScript rodar para enxergar o código que seu app realmente entrega, lê os cabeçalhos que vieram com a resposta, olha seu certificado e faz ao seu banco de dados e ao seu armazenamento de arquivos algumas perguntas que qualquer desconhecido poderia fazer.
Depois anota o que respondeu. É essa a forma toda da coisa, e é por isso que leva vinte segundos em vez de uma semana.
Essa categoria existe porque apps construídos com Lovable, Bolt, v0, Cursor, Replit, Windsurf e Base44 dão errado no mesmo punhado de lugares, e quase todos esses lugares são visíveis de fora. Uma chave secreta no bundle. Uma tabela que responde a um desconhecido. Um bucket de armazenamento que lista o próprio conteúdo. Ninguém precisa do seu código-fonte para achar qualquer um deles, porque seu app os entrega a cada visitante por construção.
O que uma varredura realmente lê
Cinco superfícies, e seus próprios visitantes baixam quatro delas sem perceber.
| O que ela lê | De onde isso vem | O que isso pega |
|---|---|---|
| Seu bundle de JavaScript | Os arquivos que um navegador baixa para rodar seu app | Chaves entregues ao navegador, os caminhos de API que ele chama, nomes de tabelas que usa |
| Seus cabeçalhos de resposta | Vão junto com cada página que sua hospedagem serve | Proteções do navegador ausentes, uma regra que responde a pedidos de qualquer site |
| As respostas do seu banco | A mesma API de projeto que o seu próprio app chama | Uma tabela entregando linhas a um pedido sem ninguém logado |
| Seus buckets de storage | A mesma API pública de armazenamento por onde seu app envia | Um bucket que lista os próprios arquivos para um desconhecido |
| Certificado e domínio | O handshake TLS e o registro público no registro de domínios | Um certificado perto de expirar, um domínio perto de vencer |
O bundle é o que surpreende as pessoas. O código do seu app precisa chegar ao navegador antes de rodar lá, então cada chave dentro dele também chega, junto com os caminhos de API que ele chama e muitas vezes os nomes das tabelas que ele lê. Um scanner aperta o mesmo F12 que um visitante curioso apertaria. Ele só é mais rápido, e lê todos os arquivos em vez do primeiro.
A pergunta ao banco de dados é a que todo mundo imagina invasiva, e é a coisa mais mansa da lista. Para descobrir se uma tabela é legível por desconhecidos, o nosso pede à API uma contagem das linhas e lê o número num cabeçalho de resposta. Uma contagem acima de zero significa que aquelas linhas estão alcançáveis. Nunca se busca uma linha, e a chave com que ele pergunta é a publicável que já está no seu bundle, que deveria mesmo estar ali.
As quatro coisas que uma varredura de URL não consegue ver
Tudo o que acontece no seu servidor, porque nada disso é enviado a um navegador.
Seu código de servidor. Edge functions, rotas de API, funções de banco, tudo o que roda dentro do Supabase ou na sua hospedagem. Um scanner pode chamar um endpoint e ler o que volta. Ele não pode ler o código que produziu aquilo, então um erro que só aparece com certas entradas fica invisível.
Suas variáveis de ambiente. As chaves que você deixou no servidor, que é exatamente onde elas pertencem. Uma varredura pode dizer que não achou um segredo no seu bundle. Ela não pode confirmar que o segredo está guardado direito, porque nunca enxerga o lugar onde você o guardou.
Seu histórico de versões. Uma chave que você commitou em março e tirou em abril sumiu do seu app e continua no seu repositório. Quem puder ver esse repositório ainda consegue lê-la, e nenhum tanto de olhar para o seu site no ar vai fazer ela aparecer.
A lógica do seu próprio app. Se um usuário logado consegue abrir o pedido de outro trocando um número no endereço. Se um formulário vai aceitar um preço que o navegador mandou. São decisões que o seu app toma sobre o que permitir, e pegar isso exige entrar na conta e testar coisas, o que é um teste de intrusão.
Existe um quinto limite que é nosso e não da categoria, e vale conhecer antes de ler um dos nossos relatórios. O Supabase não entrega mais a lista de tabelas de um projeto a uma chave publicável, então um scanner não tem como perguntar como suas tabelas se chamam. O nosso trabalha com três fontes no lugar disso: o índice do projeto em projetos mais antigos, onde ele ainda responde, os nomes de tabela que ele acha no seu próprio bundle, e uma lista de vinte e seis nomes comuns em apps feitos com vibe coding. Uma tabela aberta com um nome incomum que nunca aparece no seu código de frontend é uma que não vamos alcançar. O advisor do próprio Supabase alcança, e essa é a comparação de duas seções abaixo.
Uma varredura limpa quer dizer que meu app é seguro?
Não. Quer dizer que toda pergunta que a varredura conseguiu fazer de fora voltou limpa, e essa é uma frase menor do que parece.
Parte do motivo são os quatro pontos cegos acima. A outra parte é que uma verificação pode terminar de três jeitos e só um deles é aprovação. Uma verificação acha alguma coisa. Uma verificação pergunta e recebe um não claro. Ou uma verificação não recebe resposta nenhuma, porque o pedido expirou, o host recusou ou a página nunca terminou de carregar.
Esse terceiro final é o que decide se dá para confiar num relatório, e é o mais fácil de arredondar em silêncio para um tique. O nosso escreve «Não foi possível verificar» na linha e deixa sua nota em paz. Um tique falso seria a coisa mais danosa que este scanner poderia colocar numa tela, porque você agiria em cima dela.
É essa mesma honestidade que faz nossos próprios números publicados soarem menos alarmantes do que parecem à primeira vista. Entre 12 e 14 de agosto de 2026 rodamos essas verificações em 30.998 apps no ar feitos com vibe coding, e 99% voltaram com pelo menos um achado. Quase tudo isso é uma linha só: cabeçalhos de segurança do navegador que a plataforma de hospedagem nunca define e que a maioria dos donos num subdomínio de builder não consegue ligar por conta própria. Contar isso está certo. Ler os 99% como «quase todo app está em perigo» não está.
Varredura de URL, de repositório ou o advisor do Supabase?
Eles leem três coisas diferentes, então a pergunta útil é qual deles consegue ver o problema que você tem.
| Tipo | O que lê | O que pede de você | Onde é cego |
|---|---|---|---|
| Scanner de URL | Seu app no ar, de fora | Uma URL | Tudo o que seu servidor guarda para si |
| Scanner de repositório | Seu código-fonte e o histórico dele | Acesso ao seu repo | Se aquele código está publicado e o que suas regras fazem em produção |
| Supabase Security Advisor | A configuração daquele projeto | Sua conta do Supabase | Tudo fora do projeto: bundle, cabeçalhos, outros fornecedores |
Eles se sobrepõem bem menos do que os nomes sugerem. O advisor do Supabase percorre seu projeto e reporta problemas de configuração, entre eles tabelas com a Row Level Security mal configurada. Uma varredura de URL lê a consequência, que é se aquelas linhas estão chegando a desconhecidos agora mesmo. Os dois se separam com mais frequência do que se esperaria, porque ligar a configuração não é o mesmo que estar protegido.
Um scanner de repositório é o único dos três capaz de achar a chave que você apagou mês passado. Também é o único que não consegue dizer se o código que ele acabou de ler é o código que você publicou.
Como ler a nota
A letra é limitada pelo pior achado do relatório, então uma boa pontuação nunca salva um achado grave.
Toda varredura começa em 100. Um achado crítico custa 40 pontos, um alto 15, um médio 5, um baixo 1. Depois um teto se assenta sobre a aritmética: um achado crítico limita a nota em D, dois limitam em F, e um único achado alto limita em C. Um app no mais tudo em ordem com uma única tabela aberta sai como D, e esse é o comportamento pretendido.
O que você acertou aparece no relatório e não te custa nada. Sua chave publicável do Supabase ali no bundle é listada como correta, porque é para isso que ela serve, e pintá-la de vermelho é o jeito de uma ferramenta te ensinar a ignorar o vermelho.
O que fazer com o resultado de uma varredura
O que fazer
- Leia primeiro as linhas que dizem «Não foi possível verificar». São as perguntas ainda abertas, e não são aprovação.
- Trabalhe por gravidade. Um achado crítico quer dizer que hoje dá para chegar aos seus dados; um cabeçalho ausente é uma configuração que ninguém ligou.
- Cuide do lado de dentro à parte: mantenha as chaves secretas no servidor, vasculhe seu próprio histórico de versões atrás de chaves apagadas, e entre como usuário de teste para ver até onde ele chega.
- Escaneie de novo depois de cada publicação, e sempre que alguém mexer numa regra do banco. É a mudança sobre a qual nada te avisa.
- Se seu app recebe pagamentos ou guarda dados de saúde, contrate um teste de intrusão em algum momento. Uma verificação externa automática não é uma auditoria, e nenhuma ausência de achados é garantia.
Nosso scanner de segurança de site gratuito roda nove verificações somente de leitura em qualquer URL no ar, em uns vinte segundos e sem conta. Ele lê, nunca escreve e nunca entra na conta.
Se você preferir passar por isso na mão primeiro, o checklist de segurança de 10 minutos cobre o mesmo terreno na ordem em que vale a pena fazer.
Perguntas frequentes
O que é um scanner de segurança para vibe coding?
Uma ferramenta que carrega seu app no ar como um visitante faria e lê o que volta: o JavaScript que seu app entrega ao navegador, os cabeçalhos que sua hospedagem manda junto, o certificado e as respostas que seu banco de dados e seu armazenamento de arquivos dão a uma requisição vinda de um desconhecido. Ela precisa de uma URL e de mais nada. Ela relata o que achou na superfície pública do seu app, que é justamente onde apps construídos com IA dão errado com mais frequência.
É seguro escanear meu próprio app?
É, desde que o scanner só leia. O nosso faz o mesmo tipo de requisição que um visitante comum faz, nunca entra na conta, nunca escreve, cria ou apaga nada em lugar nenhum e nunca baixa os dados dos seus usuários. Para testar se uma tabela do banco é legível, ele pede uma contagem das linhas e lê o número, sem buscar uma única linha. O tráfego é um punhado de requisições, menos do que uma pessoa navegando no seu site por um minuto.
Uma varredura precisa do meu código-fonte ou da senha do meu banco?
Não. Um scanner de URL trabalha inteiramente de fora, então não há nada a conectar e nenhuma credencial a entregar. Esse também é o limite dele: só enxerga o que seu app já mostra a qualquer visitante. Uma ferramenta que lê seu repositório ou se conecta à conta do seu banco enxerga outras coisas, e o artigo acima coloca as três lado a lado.
Funciona com Lovable, Bolt, Cursor, Replit, v0, Windsurf e Base44?
Funciona, e com qualquer outra coisa que coloque um site no ar, porque a varredura olha o que está publicado e não o que escreveu aquilo. O builder importa para o conserto mais do que para a verificação: consertar uma tabela aberta é uma sequência de cliques diferente no Lovable e no Replit, e é por isso que o texto do conserto nomeia o seu builder.
O que um scanner de segurança não verifica?
Tudo o que fica no seu servidor. Seu código de servidor e suas funções de banco, as variáveis de ambiente que você manteve fora do navegador, a chave que você commitou e depois apagou do repositório, e os bugs da sua própria lógica, como um usuário logado conseguir abrir o pedido de outro trocando um número no endereço. Achar esse último grupo exige entrar na conta e testar coisas, e isso é um teste de intrusão e não uma varredura.
Um scanner de segurança para vibe coding é gratuito?
O nosso é, pelo menos a varredura em si: você recebe a nota, a pontuação e a quantidade de achados na tela em cerca de 20 segundos, sem conta, e os achados detalhados com os consertos depois de informar um e-mail. Existem planos pagos para o que uma varredura única não faz, que é perceber quando algo mudar no mês que vem. Uma nota é verdadeira no segundo em que você a tira.