/ TL;DR

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 é:

  1. 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".
  2. Revisão automatizada no CI. SAST focado no que o modelo esquece: secrets, SSRF, IDOR. Bloqueia merge se detecta.
  3. 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.

EV

Equipe Varredura

Time de pesquisa de segurança · Varredura

Sua app em produção passa por essa análise?

Rode uma varredura autônoma em ~60 segundos. Sem cadastro.

Analisar minha aplicação →