As 10 vulnerabilidades de código para caçar em 2026

A maioria dos vazamentos ainda começa por um punhado de classes de bugs bem conhecidas. Os frameworks ficaram mais seguros, mas os erros mudaram de lugar: foram para os handlers de API, os jobs em background, o código de infraestrutura e a cola entre serviços. Esta é a lista que verificamos primeiro em toda auditoria, com o CWE que você verá em um relatório do CodeAuditAgent.

1. Controle de acesso quebrado (CWE-639, CWE-862)

É, de longe, o achado grave mais comum: um endpoint carrega um registro pelo ID sem verificar se ele pertence a quem fez a requisição. A autenticação diz quem a pessoa é; a autorização precisa acontecer em toda e qualquer consulta.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Injeção (CWE-89, CWE-78)

SQL montado com concatenação de strings, comandos de shell e expressões de template continuam por toda parte, geralmente naquela única query que alguém escreveu à mão por questão de performance. Parametrize a query ou passe os argumentos como array; nunca concatene entrada do usuário.

3. Segredos hardcoded (CWE-798)

Chaves de API commitadas no repositório, tokens de teste que na verdade eram de produção, chaves privadas em arquivos de configuração. Mova tudo para variáveis de ambiente ou um gerenciador de segredos e rotacione qualquer coisa que já tenha sido commitada: apagar a linha não apaga o histórico.

4. Server-side request forgery (CWE-918)

Qualquer funcionalidade que busca uma URL informada pelo usuário, como webhooks, pré-visualização de links ou importações, pode ser apontada para sua rede interna ou para o endpoint de metadados da nuvem. Use uma allowlist de hosts, resolva e verifique o IP e bloqueie as faixas privadas.

5. Cross-site scripting (CWE-79)

Os frameworks modernos fazem escape por padrão, então o XSS agora se esconde nas válvulas de escape: props de HTML bruto, renderizadores de markdown e URLs colocadas em atributos href. Sanitize o HTML com uma biblioteca confiável e rejeite URLs javascript:.

6. Desserialização insegura e eval (CWE-502, CWE-95)

Pickle, carregamento de YAML, object streams do Java e eval dinâmico transformam dados em código. Use loaders seguros e JSON validado por schema.

7. Criptografia fraca (CWE-327, CWE-330)

MD5 ou SHA-1 para senhas, IVs estáticos, Math.random() para tokens. Use um hash de senha feito para isso (Argon2id, bcrypt, scrypt) e uma fonte de aleatoriedade criptograficamente segura.

8. Open redirect (CWE-601)

Um parâmetro next ou returnTo que aceita qualquer URL transforma seu domínio em uma plataforma confiável para phishing. Aceite apenas caminhos relativos da mesma origem.

9. Falta de rate limiting (CWE-307, CWE-770)

Login, redefinição de senha, OTP e qualquer endpoint que custe dinheiro (e-mail, SMS, chamadas de IA) precisam de limites por usuário e por IP. Sem eles, ataques de força bruta e de explosão da fatura são triviais.

10. Configuração de segurança incorreta (CWE-16)

CORS com curinga e credenciais, modo debug em produção, stack traces detalhados, políticas de bucket permissivas demais. Raramente parecem bugs no code review porque ficam na configuração, e é exatamente por isso que devem ser revisadas como código.

Como usar esta lista

• Verifique as classes 1 a 3 em todo pull request; são as de maior impacto e as mais fáceis de deixar passar.
• Trate a configuração de infraestrutura e de CI como código sob revisão.
• Registre o CWE em cada achado para acompanhar as correções e medir tendências.