OWASP Top 10 2025: o que mudou e como se proteger de cada risco

O OWASP Top 10 é a lista de referência dos riscos mais críticos em aplicações web, mantida pela OWASP Foundation a partir de dados de milhares de aplicações testadas e de uma pesquisa com profissionais da área. A edição 2025, apresentada em novembro de 2025, substitui a de 2021 e reflete como os ataques mudaram: menos foco em falhas pontuais de código e mais foco em configuração, dependências e falhas de projeto.

Abaixo, cada uma das dez categorias com o que ela significa na prática, um exemplo e como detectar.

O que mudou em relação a 2021

• Controle de acesso quebrado continua em primeiro e agora absorve o SSRF, que em 2021 era a categoria A10.
• Configuração incorreta de segurança subiu do quinto para o segundo lugar, reflexo de aplicações cada vez mais configuráveis e de infraestrutura como código.
• Falhas na cadeia de suprimentos de software entram como A03, ampliando a antiga categoria de componentes vulneráveis para incluir pacotes maliciosos, pipelines de build e dependências comprometidas.
• Tratamento inadequado de condições excepcionais é a nova A10, cobrindo erros mal tratados que expõem dados ou deixam o sistema em estado inseguro.
• Injeção caiu para o quinto lugar, não porque ficou menos grave, mas porque frameworks modernos a previnem por padrão.

A01:2025 Controle de acesso quebrado

Um usuário consegue fazer algo que não deveria: ver o pedido de outro cliente trocando o ID na URL (IDOR), acessar uma rota administrativa sem ser administrador, ou fazer o servidor buscar uma URL interna (SSRF).

# Vulnerável: qualquer usuário autenticado lê qualquer fatura
@app.get("/faturas/<int:fatura_id>")
@login_required
def obter_fatura(fatura_id):
    return Fatura.query.get_or_404(fatura_id).to_dict()

# Corrigido: a consulta é limitada ao dono
@app.get("/faturas/<int:fatura_id>")
@login_required
def obter_fatura(fatura_id):
    return Fatura.query.filter_by(id=fatura_id, cliente_id=current_user.id).first_or_404().to_dict()

Como detectar: ausência de verificação é difícil para regras estáticas. Os métodos mais eficazes são pentest com IA com múltiplos usuários de teste, testes de API focados em BOLA e revisão de pull request com IA, que nota quando uma rota nova não tem checagem de permissão.

A02:2025 Configuração incorreta de segurança

Contas padrão habilitadas, mensagens de erro detalhadas em produção, buckets públicos, CORS aberto, cabeçalhos de segurança ausentes, recursos de depuração ligados. É a categoria que mais cresceu.

Como detectar: CSPM para a nuvem, análise de IaC para Terraform e Kubernetes antes do deploy e DAST para cabeçalhos, TLS e páginas expostas. Veja as 12 configurações erradas mais comuns na nuvem.

A03:2025 Falhas na cadeia de suprimentos de software

Tudo o que você não escreveu mas executa: dependências com vulnerabilidades conhecidas, pacotes maliciosos publicados em registros públicos, ações de CI de terceiros, imagens base desatualizadas e sistemas de build comprometidos. Os ataques ao npm em 2025, que atingiram pacotes com bilhões de downloads semanais, mostram por que a categoria ganhou espaço próprio.

Como detectar: SCA com alcançabilidade, detecção de malware em dependências, SBOM e proteção das máquinas de desenvolvimento. Detalhes em ataques à cadeia de suprimentos.

A04:2025 Falhas criptográficas

Dados sensíveis trafegando sem TLS, senhas com hash rápido (MD5, SHA1) e sem salt, chaves embutidas no código, algoritmos obsoletos, geradores de números aleatórios previsíveis usados para tokens.

// Vulnerável: token de recuperação previsível
const token = Math.random().toString(36).slice(2);

// Corrigido: gerador criptograficamente seguro
const token = crypto.randomBytes(32).toString('base64url');

Como detectar: SAST encontra algoritmos fracos e aleatoriedade insegura; detecção de secrets encontra chaves no código; CSPM verifica criptografia em repouso.

A05:2025 Injeção

Entrada do usuário interpretada como código ou comando: SQL, NoSQL, comando do sistema, LDAP, templates e XSS, que foi incorporado a esta categoria desde 2021.

Como detectar: é o território clássico do SAST com análise de fluxo de dados. Em produção, a proteção em runtime bloqueia a injeção no momento em que ela alteraria a consulta.

A06:2025 Projeto inseguro

Falhas que nascem no desenho, não na implementação: um fluxo de recuperação de senha que confia em perguntas públicas, um checkout que aceita o preço vindo do cliente, uma API sem limite de tentativas. Código perfeito não conserta um projeto inseguro.

Como detectar: modelagem de ameaças na fase de projeto, auditoria de código com IA que raciocina sobre fluxos inteiros, e pentest focado em lógica de negócio.

A07:2025 Falhas de autenticação

Ausência de MFA, senhas fracas aceitas, sessões que não expiram, tokens JWT sem validação de assinatura ou de expiração, falta de proteção contra credential stuffing.

Como detectar: DAST e pentest para fluxos de login e sessão; SAST para validação de JWT; proteção contra bots para credential stuffing em produção.

A08:2025 Falhas de integridade de software e de dados

Atualizações sem verificação de assinatura, desserialização insegura de dados vindos do cliente, pipelines de CI que executam código não confiável de pull requests externos.

Como detectar: SAST para desserialização; análise de configuração de pipelines de CI; assinatura e proveniência de artefatos, como fazem as imagens endurecidas.

A09:2025 Falhas de registro e alerta

A aplicação não registra eventos relevantes, como falhas de login e mudanças de permissão, ou registra mas ninguém é alertado. O resultado é o incidente descoberto meses depois. A mudança de nome, de "monitoramento" para "alerta", reforça que log sem alerta não protege.

Como detectar: revisão de código para eventos de segurança; checagem de trilhas de auditoria na nuvem via CSPM; proteção em runtime que gera eventos de ataque para o seu SIEM.

A10:2025 Tratamento inadequado de condições excepcionais

Erros não tratados que expõem stack traces e dados, exceções engolidas que deixam uma transação pela metade, sistemas que "falham abertos" e liberam acesso quando um serviço de autorização cai.

// Vulnerável: se o serviço de permissões falhar, libera o acesso
async function podeAcessar(usuario: Usuario, recurso: string) {
  try {
    return await permissoes.verificar(usuario.id, recurso);
  } catch {
    return true;
  }
}

A correção é falhar fechado: em caso de erro, negar e registrar.

Como detectar: SAST para blocos que engolem exceções; análise de qualidade de código para tratamento de erro inconsistente; DAST para mensagens de erro detalhadas.

Como usar o OWASP Top 10 no seu time

O Top 10 é um documento de conscientização, não uma norma completa. Use-o para três coisas:

1. Treinamento: as dez categorias são o vocabulário mínimo de qualquer pessoa que escreve código.
2. Critério de revisão: inclua as categorias no template de pull request e no checklist de arquitetura.
3. Mapa de cobertura: para cada categoria, pergunte qual ferramenta ou processo detecta aquele risco hoje. As lacunas mostram onde investir.

Para verificações mais detalhadas, o OWASP ASVS (Application Security Verification Standard) oferece uma lista de requisitos testáveis por nível de criticidade.