OWASP Top 10:2025: o que mudou e o que isso muda na sua aplicação

Para quem já tinha processos alinhados à edição anterior, as diferenças abaixo são as que alteram escopo de teste e prioridade de correção.

• A01:2025 Broken Access Control continua em primeiro lugar e agora inclui SSRF (Server-Side Request Forgery), que em 2021 era uma categoria própria.
• A02:2025 Security Misconfiguration subiu do quinto para o segundo lugar.
• A03:2025 Software Supply Chain Failures amplia a antiga A06:2021, que tratava apenas de componentes vulneráveis e desatualizados.
• A04:2025 Cryptographic Failures caiu do segundo para o quarto lugar; A05:2025 Injection caiu do terceiro para o quinto; A06:2025 Insecure Design caiu do quarto para o sexto.
• A07:2025 Authentication Failures manteve a posição e perdeu o termo Identification do nome.
• A09:2025 passou a se chamar Security Logging and Alerting Failures, com ênfase no alerta que dispara uma ação.
• A10:2025 Mishandling of Exceptional Conditions é uma categoria nova, com 24 CWEs.

A01 reúne 40 CWEs e, nos dados da edição, somou mais de 1,8 milhão de ocorrências e 32.654 CVEs. Na prática, é o usuário que troca o número na URL de /api/pedidos/1042 para /api/pedidos/1043 e recebe o pedido de outra pessoa, o endpoint de DELETE que confere login mas não confere dono do registro, o token JWT editado para ganhar perfil de administrador e a configuração de CORS que aceita qualquer origem. Com a entrada do SSRF, também entra aqui o recurso que busca uma URL informada pelo usuário, como uma prévia de link ou um webhook, e pode ser usado para alcançar serviços internos.

O teste de A01 é feito com pelo menos duas contas de perfis e empresas diferentes, repetindo cada requisição de uma conta com os identificadores da outra. Nenhum scanner automático entende de quem é cada registro, então essa parte exige trabalho manual e conhecimento da regra de negócio.

A02 cobre 16 CWEs, incluindo XXE. O documento oficial registra que 100% das aplicações testadas tinham alguma forma de configuração incorreta. Os exemplos são conhecidos: senha padrão que nunca foi trocada, página de exemplo esquecida em produção, stack trace exibido ao usuário, bucket de armazenamento com compartilhamento público e ausência de cabeçalhos de segurança. O teste combina varredura automatizada com revisão das configurações de nuvem, e a prevenção recomendada é um processo de hardening repetível, capaz de subir um ambiente novo já travado.

A03 trata de falhas no processo de construir, distribuir ou atualizar software. Isso inclui a biblioteca com vulnerabilidade conhecida, que já estava na edição anterior, e vai além: dependência comprometida pelo próprio mantenedor, pipeline de CI/CD sem controle de acesso, pacote publicado com nome parecido com o original, ferramenta de build adulterada.

A categoria tem poucas CWEs mapeadas (5) e poucas CVEs associadas, mas foi votada em primeiro lugar por metade dos participantes da pesquisa com a comunidade e, segundo a OWASP, tem as maiores médias de pontuação de exploração e de impacto entre as CVEs. Também registra a maior taxa média de incidência da lista, 5,19%.

A verificação envolve conferir se a empresa sabe quais componentes usa, inclusive dependências transitivas, se monitora vulnerabilidades desses componentes de forma contínua e se o pipeline exige revisão antes de publicar. A OWASP recomenda manter um SBOM (inventário de componentes de software), separar funções para que nenhuma pessoa sozinha consiga levar código até produção sem revisão, proteger o CI/CD com MFA e registro de auditoria e fazer atualizações em etapas.

A04 (32 CWEs) trata de dados sensíveis sem criptografia ou com algoritmos e chaves inadequados. O teste verifica protocolo e certificados em trânsito, forma de armazenamento de senhas e onde ficam as chaves. A05 (38 CWEs) é a injeção clássica: SQL, comandos do sistema operacional e cross-site scripting. Aqui ferramentas automatizadas ajudam bastante, mas cada campo de entrada, cabeçalho e parâmetro de API precisa entrar no escopo.

A06 dificilmente aparece em varredura automática. A OWASP separa design inseguro de implementação defeituosa: um design seguro pode ter bugs, mas um design inseguro não se corrige com código perfeito, porque o controle nunca foi previsto. O exemplo do documento é uma rede de cinemas que dá desconto para grupos sem exigir depósito até quinze pessoas e permite que alguém reserve centenas de lugares em poucas requisições. O teste aqui é modelagem de ameaças e abuso deliberado da regra de negócio.

A07 (36 CWEs) cobre login, recuperação de senha, MFA e sessão. O teste inclui força bruta e credential stuffing com limite de tentativas, reaproveitamento de token após logout, sessão que não expira e fluxo de redefinição de senha que revela se um e-mail existe.

A08 trata de código e dados aceitos sem verificação de origem: script carregado de CDN não confiável, atualização automática sem assinatura, desserialização de dados vindos do cliente e pipeline que baixa artefatos de fontes externas sem conferir. A prevenção passa por assinatura digital, repositórios internos para dependências e segregação de acesso no CI/CD.

A09 mudou de nome para deixar claro que registrar eventos sem gerar alerta não resolve. Os sinais de falha listados pela OWASP incluem logins e transações de alto valor que não são registrados, logs guardados apenas no servidor local e sem cópia, ausência de limites de alerta e, um teste simples de aplicar, pentest ou varredura DAST que passa sem disparar nenhum alerta. Se a sua equipe de monitoramento não percebeu o último pentest, a aplicação tem uma falha de A09.

A categoria nova reúne 24 CWEs sobre programas que não previnem, não detectam ou não respondem a situações inesperadas. O caso mais grave é o fail open (CWE-636): quando o serviço de autorização demora ou lança exceção, o código cai num bloco catch que deixa a requisição seguir. Também entram retornos de função não verificados (CWE-252) e condições de erro ignoradas (CWE-391).

Um exemplo do próprio documento é o upload de arquivo que captura a exceção mas não libera o recurso alocado. Repetido algumas milhares de vezes, esgota a capacidade do servidor. A recomendação da OWASP é tratar a exceção no ponto onde ela ocorre, desfazer a transação inteira em caso de erro (fail closed), centralizar o tratamento de erros e impor limites e cotas, com a observação de que nada em tecnologia deveria ser ilimitado.

O teste de A10 envolve provocar falhas de propósito: enviar payloads malformados, derrubar uma dependência durante a requisição, estourar limites de tamanho e observar se a aplicação nega o acesso, se devolve detalhes internos na mensagem de erro e se deixa dados em estado parcial.

O Top 10 funciona como piso mínimo de cobertura e como vocabulário comum entre times técnicos, fornecedores e clientes. Na prática, vale atualizar três coisas: o escopo do próximo pentest, que deve citar as categorias de 2025 e incluir SSRF dentro de controle de acesso; os critérios de revisão de código, que passam a olhar tratamento de exceções; e o inventário de dependências e do pipeline, que agora tem categoria própria.

A Tox executa pentests e revisões de código usando a edição 2025 como referência de escopo, com relatório que indica a categoria de cada achado e o passo para reproduzi-lo.