SQL injection e XSS em código gerado por IA: por que o modelo erra sempre do mesmo jeito

SQL injection e XSS em código gerado por IA não aparecem de forma aleatória. Aparecem de forma sistemática, e o padrão está mais ligado a como o prompt foi escrito do que ao que o modelo sabe ou não sabe sobre segurança.

A Veracode testou mais de 100 LLMs em 80 tarefas de codificação projetadas especificamente para dar aos modelos uma escolha entre implementações seguras e inseguras. O resultado: código gerado por IA introduziu falhas de segurança em 45% dos testes, com XSS falhando em 86% das vezes. A narrativa padrão enquadra isso como um "gap de conhecimento do modelo" que revisão humana deveria capturar. Esse enquadramento está errado, e acreditar nele produz processos de segurança que não reduzem o risco na prática.

XSS falha 86% das vezes porque o prompt não dá contexto suficiente ao modelo

O número do Veracode merece mais atenção do que costuma receber, porque a explicação aponta diretamente para a estrutura do prompt, não para a capacidade do modelo.

Vulnerabilidades XSS exigem codificação de saída, e codificação de saída exige saber o contexto: você está inserindo numa atributo HTML, num bloco de script, num parâmetro de URL ou em HTML bruto? Cada contexto exige uma estratégia de escape diferente. Quando um prompt pede uma "página de perfil de usuário que exibe o nome de usuário", o modelo não sabe em qual contexto de renderização está operando. Então ele recorre ao que é mais comum nos dados de treinamento, que é interpolação de string sem escape.

Isso é testável: dê ao mesmo modelo um prompt que especifica o contexto de renderização explicitamente e pede tratamento seguro de saída, e a taxa de falha cai. O modelo sabe o que é DOMPurify e sabe o que htmlspecialchars() faz. O conhecimento existe; o prompt simplesmente não o ativou.

O problema mais profundo é que os dados de treinamento pendem para exemplos funcionais. Uma resposta no Stack Overflow que mostra como exibir input do usuário numa página é otimizada para responder à pergunta específica que foi feita, não para modelar uma postura completa de segurança. O Veracode 2025 GenAI Code Security Report atribui o padrão de falha parcialmente a isso: "as bases de código incluídas nos conjuntos de dados de treinamento têm mais probabilidade de ser funcionais do que seguras, e é improvável que sejam rotuladas como seguras ou inseguras antes de serem ingeridas."

Em Java especificamente, a taxa de falha sobe para 72%. A explicação é direta: Java é anterior ao reconhecimento formal de SQL injection como classe de vulnerabilidade, então o volume de exemplos Java legados e inseguros nos dados de treinamento é desproporcionalmente alto. O modelo aprendeu a partir do que estava disponível, e o que estava disponível foi escrito em sua maioria antes de "seguro por padrão" se tornar um objetivo de design.

O padrão de vulnerabilidade está no prompt, não no conhecimento do modelo

É aqui que o conselho genérico falha. "Sempre revise o output de IA" trata o modelo como um desenvolvedor júnior cujo código precisa de inspeção antes de ir para produção. Isso não está errado como prática, mas identifica a fonte do problema de forma equivocada e, portanto, produz a correção errada.

A leitura mais precisa: falhas de segurança de LLM em SQL injection e XSS são prompt-determinísticas. O mesmo modelo que produz uma query SQL concatenada com string bruta quando solicitado a "escrever uma função de login" vai produzir uma query parametrizada quando solicitado a "escrever uma função de login segura usando prepared statements." O comportamento do modelo muda com base no que o prompt sinaliza que deve ser otimizado.

O modelo não ignora que $_GET['id'] anexado diretamente a uma string SQL é perigoso; simplesmente não foi solicitado a se importar com isso. A implicação prática é que revisões de segurança posicionadas no final do pipeline, como um catch-all para output de IA, sempre ficarão atrás do volume de código sendo gerado.

A pesquisa de setembro de 2025 da Apiiro constatou que commits com assistência de IA eram mesclados em produção 4x mais rápido do que commits regulares, o que significa que código inseguro passa pelos ciclos normais de revisão antes que qualquer humano o veja. Até junho de 2025, código gerado por IA estava introduzindo mais de 10.000 novos achados de segurança por mês nos repositórios do estudo. Uma aceleração desse porte não é um problema que revisão no fim do pipeline foi projetada para tratar nesse volume.

A correção que realmente aborda a causa raiz é mover a especificação de segurança para dentro do prompt. Isso significa:

• Nomear o requisito de segurança explicitamente ("use prepared statements", "aplique codificação de saída sensível ao contexto")
• Especificar o contexto de renderização ou execução para que o modelo possa escolher a defesa correta
• Enquadrar a tarefa em torno da implementação segura, não só da funcional

Isso não é garantia de output seguro. É uma mudança estrutural que desloca o alvo de otimização do modelo no momento da geração, que é onde o problema de fato origina.

O problema que os números de SQLi e XSS não mostram

Corrigir classes de vulnerabilidade individuais nos prompts não resolve o padrão maior que os dados da Apiiro revelam. Erros de sintaxe em código escrito por IA caíram 76% e bugs lógicos recuaram mais de 60%, que é a melhoria que times costumam citar quando argumentam que assistentes de IA são positivos para qualidade de código. Esses números são reais. O tradeoff é o que recebe menos atenção: caminhos de escalada de privilégios saltaram 322%, e falhas de design arquitetural aumentaram 153% no mesmo conjunto de dados.

SQL injection e XSS são vulnerabilidades rasas no sentido de que são detectáveis no nível de função. Uma única query parametrizada substitui uma única string interpolada. As falhas arquiteturais que a Apiiro está rastreando, controle de acesso excessivamente permissivo, relacionamentos de confiança inseguros entre serviços, camadas de autorização ausentes, não se resolvem com uma instrução no prompt porque emergem de como os componentes se relacionam entre si, não de como qualquer função individual é escrita.

Isso importa para como você lê os números de XSS e SQLi. Uma taxa de aprovação de 80% em SQL injection parece progresso até você reconhecer que os 20% de falha ainda representam volume significativo em escala, e que o mesmo fluxo de geração de código está simultaneamente produzindo caminhos de escalada de privilégios a três vezes a taxa anterior. Corrigir a classe rasa não neutraliza a arquitetural. Se for alguma coisa, a melhoria de velocidade que assistentes de IA proporcionam significa que ambas as categorias chegam à produção mais rápido do que antes.

Itay Nussbaum, da Apiiro, disse diretamente ao The Register: "IA está multiplicando não um tipo de vulnerabilidade, mas todos eles ao mesmo tempo." O corolário para times usando desenvolvimento com assistência de IA é que especificações de segurança no nível do prompt endereçam uma camada do problema, e ferramentas dedicadas de segurança de aplicação precisam endereçar o restante em paralelo, não como um catch downstream.

Se você está pensando em como a estrutura do prompt se relaciona com o que o modelo produz no nível de sistema, a mecânica aqui se conecta diretamente ao que está coberto em red-teaming de system prompts contra injection antes de ir a produção. O ângulo de contaminação de dados de treinamento se sobrepõe aos padrões documentados em segredos hardcoded em codebases com assistência de IA.

Na prática

No meu trabalho com catálogo e integrações de marketplace, não escrevo código de produção, mas uso ferramentas de IA regularmente para gerar scripts de transformação de dados, validação de feeds e mapeamento de eventos no GA4. O padrão que observei, sem nenhum teste controlado, é que a qualidade do output em questões adjacentes a segurança, como sanitização de dados ou validação de input, acompanha quase diretamente o quão explicitamente eu nomeio o requisito no prompt.

Quando descrevo o que quero que o script faça, recebo algo funcional. Quando adiciono uma linha sobre como input não confiável deve ser tratado, o output muda de forma visível. Se essa diferença se traduz em segurança real, é algo que alguém com expertise em AppSec precisa avaliar, mas a diferença de comportamento no modelo é consistente o suficiente para parar de parecer coincidência depois das primeiras iterações.

FAQ

Usar um modelo mais capaz (GPT-4o, Claude 3.5 Sonnet, etc.) reduz significativamente as taxas de SQL injection e XSS?

O relatório da Veracode testou mais de 100 modelos lançados entre março de 2023 e maio de 2025. Modelos mais novos mostram melhoria em alguns tipos de vulnerabilidade, mas nenhum modelo no estudo alcançou output consistentemente seguro sem enquadramento explícito de segurança no prompt. Nível de capacidade ajuda nas margens, mas não elimina a dependência do prompt. O relatório completo detalha os resultados por geração de modelo.

Análise estática é suficiente para capturar vulnerabilidades geradas por IA antes de irem a produção?

Para vulnerabilidades rasas como SQL injection e XSS, ferramentas SAST capturam uma porcentagem razoável. Para as falhas arquiteturais que a Apiiro documenta, escalada de privilégios, confiança insegura entre serviços, análise estática sozinha é insuficiente porque esses problemas emergem de relacionamentos entre componentes que análise de arquivo único não modela bem. A resposta para a maioria dos times é SAST mais DAST mais revisão manual em caminhos críticos de segurança, não nenhuma ferramenta única isolada.

Por que Java performa tão pior do que Python ou JavaScript nos testes da Veracode?

A explicação da Veracode é a composição dos dados de treinamento. Java como linguagem é anterior à classificação formal de SQL injection como vulnerabilidade, então o volume de exemplos Java legados e pré-conscientização de segurança em repositórios públicos é desproporcionalmente grande. Modelos treinados nesse corpus aprendem padrões de código escrito antes de "seguro por padrão" ser uma norma de design. Python e JavaScript têm taxas de falha menores, embora 38% e 43% respectivamente não sejam números que alguém deveria achar tranquilizadores.

O ponto mais limpo da metodologia controlada da Veracode é que o mesmo modelo passa em tarefas de segurança explícitas e falha em tarefas implícitas. Isso significa que a responsabilidade pelos padrões de vulnerabilidade gerados por IA está no fluxo de prompting, não exclusivamente no treinamento do modelo. É um insight mais acionável do que "revise o output de IA", porque identifica onde no processo a intervenção realmente precisa acontecer.