📄 other

Hardening vibe-coded web applications with an automated security-audit skill: a controlled comparison of two builds of the same app

Este artigo demonstra que integrar uma habilidade de auditoria de segurança automatizada ao processo de "vibe coding" melhora drasticamente a segurança de aplicações web geradas por IA, reduzindo o risco não mitigado em 99% e eliminando todas as vulnerabilidades de alta severidade em uma comparação controlada de duas versões de um mesmo demo de e-commerce.

Autores originais: Piyush Omanwar

Publicado 2026-07-25

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Piyush Omanwar

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está construindo uma casa, mas em vez de assentar os tijolos você mesmo, você pede a um robô incrivelmente rápido e talentoso para fazer isso. Você dá ao robô uma frase simples como: "Construa para mim um chalé aconchegante com uma porta vermelha" e, em segundos, ele lhe entrega uma casa com aparência perfeita. Este é o mundo da "vibe coding", onde a inteligência artificial (IA) escreve aplicativos inteiros funcionais a partir de comandos curtos. É como mágica: você obtém um produto acabado instantaneamente. Mas aqui está a armadilha: o robô é ótimo em fazer as coisas parecerem boas e funcionarem rápido, mas muitas vezes ele esquece as partes chatas e invisíveis de segurança. Ele pode deixar a porta da frente destrancada, esquecer de instalar detectores de fumaça ou deixar o portão dos fundos aberto porque essas coisas não tornam a casa bonita em um tour rápido.

No mundo da segurança da computação, essas lacunas invisíveis são chamadas de vulnerabilidades. Pense nelas como rachaduras ocultas na fundação ou janelas que não trancam. Para uma equipe profissional, existem guardas de segurança (especialistas humanos) que verificam essas coisas antes que alguém se mude. Mas para o construtor solo que usa IA, não há mais ninguém verificando. O robô apenas lhe entrega as chaves, e o construtor pode nem saber que a casa é insegura. Este artigo faz uma pergunta simples e crucial: Se construirmos exatamente a mesma casa duas vezes — uma vez com o robô sozinho, e outra vez com o robô mais um "inspetor de segurança" especial que verifica seu próprio trabalho — o quanto essa segunda casa se torna mais segura? Os pesquisadores queriam ver se adicionar uma verificação automatizada simples poderia transformar um aplicativo instável e inseguro em uma fortaleza sem diminuir a diversão e a rapidez da construção por "vibe".

O Experimento: Dois Apps, Uma Grande Diferença

Os pesquisadores configuraram um experimento controlado usando uma loja online falsa chamada "Northwind". Eles pediram a uma IA para construir esta loja duas vezes. A primeira versão, vamos chamá-la de App A, foi construída apenas com o robô. A segunda versão, App B, foi construída com o mesmo robô, mas desta vez o robô tinha uma habilidade especial de "auditoria de segurança" acoplada a ele. Essa habilidade é como um inspetor incansável que executa um ciclo de cinco etapas: ele varre o código, sinaliza problemas, corrige-os e depois varre novamente para garantir que a correção realmente funcionou.

A chave deste experimento foi que a única diferença entre os dois aplicativos foi essa habilidade de segurança. O comando dado à IA foi idêntico, e as funcionalidades principais (os produtos, o carrinho de compras, o checkout) eram exatamente as mesmas. Isso garantiu que qualquer diferença na segurança não fosse porque a IA teve sorte ou mudou o design, mas puramente por causa do inspetor de segurança.

Os Resultados: Um Aumento Massivo de Segurança

Os resultados foram dramáticos. Quando pontuaram ambos os aplicativos em uma escala de 100 baseada em 16 regras de segurança diferentes (como ter uma "Política de Segurança de Conteúdo", que é um livro de regras dizendo ao navegador quais scripts ele tem permissão para executar, e uma "Política de Referenciador", que impede que o app vaze seu histórico de navegação para outros sites), a diferença foi enorme.

App A (Sem Habilidade de Segurança): Obteve uma pontuação de 58 de 100. Tinha 16 problemas de segurança, incluindo quatro lacunas de "alta severidade". Estas eram os buracos perigosos, como a falta de trancas na porta da frente. O "risco" total foi medido em 100 unidades.
App B (Com Habilidade de Segurança): Obteve uma pontuação de 99 de 100. A habilidade de segurança corrigiu quase tudo. Ela eliminou todas as quatro lacunas de alta severidade e reduziu o número total de problemas de 16 para apenas 1. O risco total caiu de 100 unidades para 1 unidade.

Em números simples, a habilidade de segurança cortou o risco não mitigado em 99,0%. O único risco restante era uma verificação específica que requer um servidor backend real (que este demo não possuía), então a habilidade honestamente sinalizou isso como algo que ainda precisava de atenção humana, em vez de fingir que estava corrigido.

Por Que Isso Importa: O Bônus do "Glitch"

Uma das descobertas mais interessantes não foi apenas sobre deter hackers, mas sobre evitar que o próprio app quebrasse. Os pesquisadores descobriram que, se você apenas adicionar regras de segurança estritas a um app bagunçado, o app costuma quebrar. Por exemplo, se você disser ao navegador "Nenhum script externo permitido", mas o app tiver um código que tenta usar scripts externos, o app para de funcionar.

A habilidade de segurança foi inteligente o suficiente para perceber isso. Antes de adicionar as regras estritas, ela voltou e limpou o código, movendo estilos e scripts para os lugares corretos para que o app ainda parecesse e funcionasse perfeitamente. Ela evitou "glitches" (falhas) que um construtor humano poderia não notar até que fosse tarde demais. Ela não apenas tapou buracos; ela reforçou toda a estrutura para que as regras de segurança não causassem o colapso da casa.

O Que o Artigo Diz (e O Que Não Diz)

O artigo é muito claro sobre o que ele não prova. Ele não afirma que o app agora é "invencível" ou que você pode parar de se preocupar com segurança totalmente. Os autores enfatizam que este é um demo estático (uma loja falsa com pagamentos falsos) e que aplicativos do mundo real, com dinheiro real e dados reais de usuários, ainda precisam de especialistas humanos em segurança para realizar testes de penetração profundos. A melhoria de 99% é específica para os controles que a habilidade consegue automatizar nesse tipo de aplicativo.

No entanto, o artigo sugere fortemente que, para os milhões de pequenos aplicativos sendo construídos por entusiastas e desenvolvedores solo usando IA, esse tipo de auditoria automatizada e integrada é um divisor de águas. Sugere que, ao incorporar verificações de segurança diretamente no fluxo de trabalho da IA, podemos elevar o "piso de segurança" do software em uma quantidade massiva, transformando o que costumava ser um hábito perigoso de "vibe coding" em algo muito mais confiável. O estudo conclui que essa abordagem é um passo barato e de alto impacto que torna o software gerado por IA aproximadamente duas ordens de magnitude mais seguro, simplesmente ao tornar o caminho seguro o caminho padrão.

Resumo Técnico: Fortalecimento de Aplicações Web "Vibe-Coded" com uma Skill de Auditoria de Segurança Automatizada

Definição do Problema
A ascensão do "vibe coding" — a prática de gerar aplicações completas e funcionais a partir de prompts curtos em linguagem natural usando Grandes Modelos de Linguagem (LLMs) — democratizou a criação de software, mas introduziu uma lacuna de segurança crítica. Embora os LLMs se destaqum na produção de código funcional, eles rotineiramente omitem controles de segurança essenciais (ex: Políticas de Segurança de Conteúdo [CSP], Políticas de Referência, gestão de segredos) porque estes não contribuem para o estado imediato de "execução" da aplicação. Isso deixa desenvolvedores amadores e solo, que carecem de equipes dedicadas de segurança, lançando aplicações com vulnerabilidades triviais, porém exploráveis. O artigo postula que, para que o software gerado por IA escale com segurança, as correções de segurança devem ser incorporadas dentro da própria etapa de geração, em vez de aplicadas como uma revisão pós-hoc, o que não escala para milhões de pequenas aplicações geradas rapidamente.

Metodologia
Os autores conduziram um experimento controlado comparando duas versões de uma mesma aplicação estática de e-commerce ("Northwind"), geradas a partir de um prompt idêntico.

Experimento 1 (Sem Skill): A aplicação foi gerada sem qualquer ferramenta de segurança.
Experimento 1.2 (Com Skill): A aplicação foi gerada utilizando a skill "Vibe App Security Audit", um agente automatizado que executa um loop de cinco fases: escaneamento, sinalização, correção e re-escaneamento.

A Skill de Auditoria:
A skill opera sobre um checklist de engenharia de 50 pontos cobrindo segredos, cabeçalhos, autenticação e integridade de pagamentos. Ela executa cinco fases específicas:

Detecção de Segredos: Identifica credenciais codificadas diretamente no código (hardcoded).
Passagem de Dados Pessoais: Mapeia o tratamento de dados sensíveis.
Higiene Pré-implantação: Remove logs de depuração e marcadores internos.
Revisão de Lógica Profunda: Analisa autorização, injeção e integridade de pagamentos.
Visão do Atacante: Simula uma perspectiva adversarial para encontrar problemas omitidos.

O estudo utilizou um modelo de Unidade de Exposição de Risco (REU) para quantificar os resultados. Este modelo atribui pesos a 16 controles de segurança em quatro categorias (Implantação/Transporte, Dados/Privacidade, Pré-implantação/Lógica Profunda, Pagamento/Financeiro). O risco residual ( $R$ ) é calculado como a soma dos pesos não mitigados: $R = \sum w_i(1 - m_i)$ , onde $m_i$ é a fração de mitigação.

Principais Contribuições

Comparação Controlada: Um teste A/B rigoroso isolando o impacto da skill de segurança ao manter a lógica funcional (JavaScript) idêntica entre as builds, garantindo que as diferenças se devam exclusivamente ao loop de auditoria.
Modelo de Pontuação Quantitativa: Um framework ponderado (REU) que prioriza riscos de alta severidade sobre simples contagens de achados, fornecendo uma "Pontuação de Postura de Segurança" (0–100).
Verificação Matemática: O artigo fornece provas formais para todas as alegações quantitativas, incluindo redução de risco, pontuações de postura e eficácia da Política de Segurança de Conteúdo (CSP).
Melhorias no Loop V4: Introdução de detecção de XSS consciente de contexto (reduzindo falsos positivos ao identificar sanitizadores no contexto do código) e análise de eficácia de CSP.
Experimentos de Gateway de Pagamento: Validação de controles de segurança através de Stripe, PayPal, Square e webhooks customizados, testando especificamente a verificação do lado do servidor para totais de pedidos.

Resultados
A aplicação da skill de auditoria de segurança resultou em melhorias significativas:

Redução de Risco: O risco residual não mitigado caiu de 100 unidades para 1 unidade, representando uma redução de 99,0%. A única unidade restante corresponde à verificação de pedidos no lado do servidor, que não pode ser abordada em um demo estático e do lado do cliente.
Pontuação de Postura de Segurança: Aumentou de 58 para 99 de 100. A base de 58 foi compartilhada por ambas as builds (devido à codificação segura inerente, como validação de Luhn e codificação de saída), enquanto a skill adicionou 41 pontos de endurecimento (hardening).
Redução de Achados:
- O total de achados caiu de 16 para 1 (uma redução de 93,8%).
- Todos os quatro gaps de alta severidade (ausência de CSP, ausência de defesa contra clickjacking, ausência de revisão de XSS de lógica profunda, ausência de revisão de atacante) foram eliminados.
- O score de risco ponderado pela severidade caiu de 100 para 48.
Eficácia da CSP: A build com a skill alcançou uma pontuação de eficácia de CSP perfeita de 100/100 ao implementar diretivas estritas (script-src 'self', frame-ancestors 'none', etc.), enquanto a build sem a skill teve uma pontuação de 0.
Prevenção de Glitches: A skill moveu proativamente estilos inline para folhas de estilo externas para evitar a quebra de layout quando CSPs estritas são aplicadas, um "defeito latente" que a build sem a skill teria enviado para produção.

Significância e Alegações
O artigo argumenta que o principal valor da skill não é ensinar novas capacidades ao LLM, mas impor um caminho seguro padrão e verificar se esse caminho foi seguido. A redução de risco de 99% é atribuída à inclusão sistemática de cabeçalhos de implantação e redes de segurança de processo que os LLMs tipicamente omitem porque são "invisíveis" para o usuário.

Os autores concluem que incorporar uma skill de auditoria de segurança automatizada e baseada em loop no fluxo de trabalho de vibe-coding eleva a base de segurança do software gerado por IA em aproximadamente duas ordens de magnitude. Eles enfatizam que esta abordagem é um "passo barato e de alto impacto" que transforma a segurança de uma fase pós-geração em uma propriedade padrão do fluxo de geração.

Limitações
O estudo reconhece que o valor de 99% aplica-se especificamente ao conjunto definido de controles dentro de uma arquitetura estática e do lado do cliente. Não pretende alegar invulnerabilidade; o risco único restante (verificação no lado do servidor) destaca a necessidade de integração de backend. Os autores declaram explicitamente que para aplicações que lidam com dinheiro real ou dados sensíveis, esta auditoria automatizada é necessária, mas não suficiente, devendo ser seguida por revisão humana e testes de penetração profissionais. Os pesos usados no modelo de pontuação baseiam-se em julgamento de especialistas, não em modelos de ameaças formais ou dados de exploração.

O Experimento: Dois Apps, Uma Grande Diferença

Os Resultados: Um Aumento Massivo de Segurança

Por Que Isso Importa: O Bônus do "Glitch"

O Que o Artigo Diz (e O Que Não Diz)

Mais como este