O OWASP Top 10 é a referência mais citada quando o assunto é segurança de aplicações web. A edição 2025, a oitava da lista, é a versão oficial publicada pela OWASP e trouxe mudanças relevantes em relação a 2021: duas categorias novas, uma fusão e várias trocas de posição. Abaixo, cada categoria, o que mudou e como usar a lista sem tratá-la como checklist completo.
O que é o OWASP Top 10
A própria OWASP define o Top 10 como um documento de conscientização: um consenso amplo sobre os riscos mais críticos para aplicações web. Cada categoria agrupa várias fraquezas do catálogo CWE, mantido pelo MITRE, sob um nome comum. Na edição 2025, as dez categorias reúnem 248 CWEs.
A metodologia é "informada por dados, mas não cegamente guiada por eles". Oito categorias vêm de dados de testes doados por empresas e pesquisadores, que segundo a OWASP cobrem mais de 2,8 milhões de aplicações. As outras duas vêm de uma pesquisa com profissionais da área, para capturar riscos que as ferramentas ainda não conseguem medir em escala.
As dez categorias da edição 2025
- A01 – Broken Access Control (quebra de controle de acesso). O usuário consegue agir fora das permissões que deveria ter: ver dados de outro cliente, acessar funções administrativas, alterar registros alheios. Continua em primeiro lugar e agora inclui o SSRF.
- A02 – Security Misconfiguration (configuração insegura). Padrões inseguros, serviços e contas desnecessários, mensagens de erro verbosas, cabeçalhos ausentes, armazenamento em nuvem mal configurado. Cresce à medida que mais comportamento da aplicação depende de configuração.
- A03 – Software Supply Chain Failures (falhas na cadeia de suprimentos de software). Comprometimentos ou fragilidades no processo de construir, distribuir ou atualizar software: dependências vulneráveis ou abandonadas, alterações maliciosas em componentes de terceiros, pipelines de build sem controle.
- A04 – Cryptographic Failures (falhas criptográficas). Ausência de criptografia onde ela é necessária, algoritmos fracos, chaves mal geridas ou dados sensíveis trafegando e armazenados em claro.
- A05 – Injection (injeção). Dados não confiáveis interpretados como comando ou consulta. Vai do Cross-site Scripting, frequente e em geral de menor impacto, ao SQL Injection, menos frequente e de alto impacto.
- A06 – Insecure Design (design inseguro). Falhas que nascem na arquitetura e na lógica de negócio, não na implementação: um fluxo sem limite de tentativas ou uma regra de negócio que pode ser contornada.
- A07 – Authentication Failures (falhas de autenticação). Senhas fracas aceitas, ausência de proteção contra ataques automatizados de credenciais, sessões mal gerenciadas, recuperação de conta frágil.
- A08 – Software or Data Integrity Failures (falhas de integridade de software ou de dados). A aplicação confia em código, atualizações ou dados sem verificar sua integridade, como desserialização insegura ou atualização automática sem assinatura.
- A09 – Security Logging and Alerting Failures (falhas de registro e alerta). Eventos relevantes não são registrados, ou são registrados sem que ninguém seja alertado. Log sem alerta pouco ajuda a detectar um incidente.
- A10 – Mishandling of Exceptional Conditions (tratamento inadequado de condições excepcionais). A aplicação não previne, não detecta ou responde mal a situações anormais: erros que vazam informação, exceções não tratadas, lógica que "falha aberta" e libera acesso quando algo dá errado.
O que mudou em relação a 2021
- Duas categorias novas. A03, Software Supply Chain Failures, amplia a antiga A06:2021 (Vulnerable and Outdated Components) para toda a cadeia de dependências, build e distribuição. Segundo a OWASP, foi o risco mais votado na pesquisa com a comunidade e tem as maiores notas médias de exploração e impacto entre as CVEs analisadas. A10, Mishandling of Exceptional Conditions, é inédita e reúne erros de tratamento de exceção e de lógica antes dispersos em "qualidade de código".
- Uma fusão. O Server-Side Request Forgery, que era a A10:2021, foi incorporado à A01, Broken Access Control.
- Quem subiu. Security Misconfiguration passou de 5º para 2º lugar.
- Quem desceu. Cryptographic Failures caiu de 2º para 4º, Injection de 3º para 5º e Insecure Design de 4º para 6º. Para Insecure Design, a OWASP atribui parte da queda a avanços do setor em modelagem de ameaças.
- Quem ficou, com outro nome. A07 perdeu o "Identification" do nome (era Identification and Authentication Failures). A09 trocou "Monitoring" por "Alerting", para enfatizar que registrar sem alertar não basta. A08 manteve a posição.
Cair no ranking não significa risco resolvido: segundo a OWASP, injeção continua sendo a categoria com mais CVEs associadas.
Como usar o Top 10 (e como não usar)
A OWASP é explícita: o Top 10 é um ponto de partida, não uma lista completa. Ela desaconselha qualquer alegação de "cobertura total do OWASP Top 10", inclusive por fabricantes de ferramentas, porque categorias como Insecure Design não podem ser detectadas de forma automatizada.
- Conscientização e treinamento. É onde o Top 10 brilha: dar a desenvolvedores, produto e gestão um vocabulário comum sobre os riscos mais relevantes.
- Requisitos e verificação. Para um padrão verificável, a recomendação da própria OWASP é o ASVS (Application Security Verification Standard), hoje na versão 5.0.0, com requisitos organizados por níveis que podem entrar em histórias de usuário, critérios de aceite e contratos com fornecedores.
- Testes. O WSTG (Web Security Testing Guide) descreve como testar cada área de uma aplicação web e é a metodologia de referência para pentest de aplicações.
Em uma frase. Use o Top 10 para saber onde olhar primeiro, o ASVS para definir o que exigir e o WSTG para definir como testar.
Como testar uma aplicação contra esses riscos
Nenhuma técnica sozinha cobre as dez categorias:
- SAST (análise estática). Examina o código-fonte em busca de padrões inseguros, como concatenação de entrada em consultas ou criptografia fraca. Roda cedo no pipeline, mas gera falsos positivos e não entende regra de negócio.
- SCA e inventário de componentes. Identifica bibliotecas e versões em uso, inclusive dependências transitivas. É a base para tratar a A03, junto com controles sobre o pipeline de build.
- DAST (análise dinâmica). Testa a aplicação em execução, de fora para dentro. Bom para injeção, configuração e cabeçalhos; fraco para autorização entre usuários e lógica de negócio.
- Revisão de código manual. Encontra o que ferramentas não veem: verificação de permissão ausente em um endpoint, tratamento de exceção que falha aberto, decisão de design insegura.
- Pentest de aplicação. Testadores exploram a aplicação como um atacante, seguindo uma metodologia como o WSTG, com foco no que ferramentas automáticas detectam mal: controle de acesso (A01), autenticação (A07), lógica de negócio e condições excepcionais (A10). Em modo gray box, com credenciais de perfis diferentes, é a forma mais direta de provar se um usuário consegue acessar dados de outro.
Há riscos que só se avaliam conversando com as pessoas e olhando o processo. A própria OWASP lembra que verificar se o registro e o alerta funcionam de fato (A09) exige entrevistas e evidências de resposta a incidentes, e que o design inseguro (A06) está além do alcance da maioria dos testes. Por isso, modelagem de ameaças na fase de design e integração dos logs da aplicação ao monitoramento de segurança completam o quadro.
Veja também pentest ou scan de vulnerabilidades e como priorizar vulnerabilidades com CVSS, EPSS e KEV.
Perguntas frequentes
A edição 2025 do OWASP Top 10 já é a versão oficial?
Sim. O site oficial da OWASP apresenta o Top 10:2025 como a edição publicada, com as dez categorias A01 a A10 descritas neste artigo. A edição 2021 continua disponível para consulta e comparação.
Atender ao OWASP Top 10 garante que minha aplicação está segura?
Não. O Top 10 cobre os riscos mais críticos, não todos, e a OWASP o descreve como o mínimo. Para um padrão de requisitos completo e verificável, use o ASVS; para a metodologia de testes, o WSTG.
Uma ferramenta automatizada consegue cobrir todo o Top 10?
Não. A própria OWASP afirma que ferramentas não conseguem detectar, testar ou proteger de forma abrangente contra todas as categorias, com destaque para Insecure Design. Ferramentas são essenciais para escala; revisão manual e pentest cobrem o que elas não alcançam.
Fontes consultadas em 10 de outubro de 2026: OWASP, OWASP Top 10:2025 (introdução, páginas de cada categoria, "Establishing a Modern Application Security Program" e "Next Steps"); OWASP, OWASP Top 10:2021; OWASP Application Security Verification Standard (ASVS) 5.0.0; OWASP Web Security Testing Guide (WSTG); MITRE, Common Weakness Enumeration (CWE). Este artigo é educacional; consulte o texto oficial da OWASP para a descrição completa de cada categoria e das CWEs mapeadas.