Cursor, Copilot, v0 e Windsurf aceleraram entrega, mas introduziram um padrão previsível de vulnerabilidades. Análise de 500 apps auditados pela Varredura em 2026 mostra que 87% carregam pelo menos uma das 12 falhas deste guia. Como identificá-las e blindar.
Em 2026, "vibe coding" — o ato de gerar código a partir de um prompt em vez de digitar — deixou de ser exceção. Cursor, GitHub Copilot, v0 e Windsurf hoje escrevem uma fatia significativa do que vai para produção em times pequenos e médios. A entrega acelerou. A superfície de ataque também.
Este guia lista as 12 vulnerabilidades que a Varredura mais encontrou em código gerado por IA no último trimestre, com o padrão de como cada uma nasce e o que pedir ao modelo (ou ao humano) para evitá-la.
O padrão
Modelos de código são otimizados para "resolver o problema imediato". Segurança é um problema separado do problema imediato: raramente aparece no prompt, quase nunca no exemplo, e o modelo prefere o código mais legível ao código mais defensivo. O resultado é previsível.
As 12 vulnerabilidades
1. Falta de validação em endpoints públicos
O modelo aceita alegre o request e usa o payload direto. Sem tipos, sem tamanhos, sem allowlist de campos. Padrão em API generators.
Padrão a pedir: "valide com Zod/Joi/Pydantic ANTES de qualquer uso; rejeite campos extras".
2. SQL montado por concatenação de string
Especialmente em prompts que fogem do ORM ("me faz um query bruto pra performance"). O modelo cai em concat direta.
Padrão a pedir: "sempre parameterized queries; nunca concat com input".
3. Autenticação sem verificação de escopo
O modelo produz if (user.isLoggedIn) mas não checa se o user é dono do recurso. IDOR clássico.
Padrão a pedir: "toda query que recebe ID vindo do request precisa incluir a cláusula de propriedade do usuário".
4. JWT com secret hardcoded
const SECRET = "changeme" no meio do código. Aparece muito em exemplos que o modelo aprendeu.
Padrão a pedir: "secrets sempre via variável de ambiente; falhar hard no boot se ausente".
5. CORS aberto (Access-Control-Allow-Origin: *)
O modelo resolve o erro no console do desenvolvedor abrindo tudo, e ninguém volta pra fechar.
Padrão a pedir: "CORS restrito a uma allowlist de domínios; se precisar de wildcard, é sinal de problema arquitetural".
6. Ausência de rate limiting
Rota nova sobe sem middleware de rate limit. Payment, signup e login são os alvos preferidos.
Padrão a pedir: "toda rota pública precisa de rate limit; toda rota de mutation precisa de rate limit específico do usuário".
7. XSS por render de HTML sem escape
O modelo usa innerHTML = user.bio ou dangerouslySetInnerHTML sem pensar.
Padrão a pedir: "nunca render HTML derivado de input do usuário sem sanitização por biblioteca dedicada (DOMPurify)".
8. Upload sem checagem de tipo/tamanho
upload(file) que aceita qualquer content-type e qualquer tamanho. Vira DoS de disco e ainda serve executáveis via URL pública.
Padrão a pedir: "allowlist estrita de MIME e tamanho máximo; verificar magic bytes, não só extensão".
9. Server-Side Request Forgery (SSRF)
Toda vez que o modelo produz "fetch a URL do usuário", entra SSRF potencial. Detalhes no artigo Anatomia de uma SSRF.
Padrão a pedir: "wrapper HTTP centralizado com resolução de DNS controlada e allowlist de faixas de IP".
10. Logs vazando dados sensíveis
console.log(req.body) em request de signup = senha, token e CPF no log. Aparece por default em código de debug que sobe sem limpar.
Padrão a pedir: "logger sanitiza automaticamente campos sensíveis; nunca console.log de request bruto".
11. Dependências desatualizadas com CVE conhecidas
O modelo escolhe versões antigas de libs porque foi treinado com código de meses atrás. Nenhum modelo tem "senso de CVE recente".
Padrão a pedir: "sempre a versão estável mais recente; rodar npm audit/pip-audit no CI".
12. Prompt injection em features de IA
A feature "resumo automático" que passa input do usuário direto para o modelo. Ou pior: passa dados de outros usuários pro mesmo modelo, e o input do atacante manda o modelo revelar.
Padrão a pedir: "toda entrada do usuário para um LLM passa por sandbox de prompt; nunca misture instruções do sistema com dados do usuário no mesmo turno sem delimitadores".
Dados de 500 apps auditados
Nos 500 apps que a Varredura auditou entre junho e agosto de 2026, encontramos:
- 87% tinham pelo menos uma dessas 12
- 62% tinham 3 ou mais
- 41% tinham SQL injection (mesmo em apps com ORM — em queries brutas para relatórios)
- 34% tinham SSRF em pelo menos um endpoint
- 28% rodavam com JWT secret hardcoded ou default
A moda foi 4 falhas por app. A mediana, 3.
O que fazer sem parar de usar IA
Vibe coding não vai voltar. O que muda o resultado é:
- Checklist no prompt. Um bloco fixo em todo prompt de código: "valide input, use ORM, sem secret no código, sem CORS aberto, com rate limit, sem console.log de request bruto".
- Revisão automatizada no CI. SAST focado no que o modelo esquece: secrets, SSRF, IDOR. Bloqueia merge se detecta.
- Varredura em produção. Porque testar o build é diferente de testar o app rodando. É o que a Varredura faz.
TL;DR
Modelos são ótimos em produzir código que roda. Ruins em produzir código que resiste. Assumir isso e adicionar duas camadas — checklist no prompt e varredura no runtime — é o diferencial entre acelerar entrega e acelerar incidente.
Sua app em produção passa por essa análise?
Rode uma varredura autônoma em ~60 segundos. Sem cadastro.