OWASP Top 10 (2025): as vulnerabilidades mais críticas em aplicações web e como corrigi-las

Aplicações web são o principal vetor de ataque contra organizações. Segundo o relatório Verizon DBIR, mais de 40% das violações de dados envolvem exploração direta de vulnerabilidades em aplicações web. Para qualquer analista de segurança, conhecer o OWASP Top 10 não é opcional — é o ponto de partida para proteger a superfície de ataque da organização.

Este guia cobre cada uma das 10 vulnerabilidades da edição 2025, publicada pela OWASP com mudanças significativas em relação à versão anterior. Além da explicação técnica de cada categoria, você encontra exemplos práticos, medidas de prevenção e como testes DAST autenticados identificam cada falha com evidência completa.

---

O que é a OWASP?

A OWASP (Open Worldwide Application Security Project) é uma fundação sem fins lucrativos dedicada a melhorar a segurança de software. Fundada em 2001, a OWASP mantém projetos de código aberto, ferramentas, documentação e comunidades que orientam desenvolvedores e equipes de segurança em todo o mundo.

O projeto mais conhecido da OWASP é o OWASP Top 10, uma lista de consenso que classifica as vulnerabilidades mais críticas em aplicações web. A lista é atualizada periodicamente com base em dados reais coletados de centenas de organizações, abrangendo milhares de aplicações e milhões de vulnerabilidades.

Para analistas que operam dentro de um programa de Continuous Threat Exposure Management (CTEM), o OWASP Top 10 funciona como referência para definir o que testar, priorizar e remediar em aplicações web.

---

O que mudou do OWASP Top 10 2021 para 2025

A edição 2025 trouxe mudanças importantes que refletem a evolução do cenário de ameaças. Duas categorias são inteiramente novas, posições foram reorganizadas e algumas categorias tiveram escopo ajustado.

Tabela comparativa: OWASP 2021 vs 2025

Principais destaques

• Security Misconfiguration subiu para #2 — refletindo a explosão de falhas de configuração em ambientes cloud e containers.
• Software Supply Chain Failures é a grande novidade — ataques como Log4Shell, SolarWinds e Codecov demonstraram que a cadeia de suprimentos de software é um vetor crítico. Essa categoria evolui a antiga A06 (Vulnerable Components) para cobrir também pipelines CI/CD e dependências maliciosas.
• SSRF deixou de ser categoria independente — foi incorporada ao Broken Access Control (A01), já que SSRF é essencialmente uma falha de controle de acesso no lado do servidor.
• Mishandling of Exceptional Conditions (A10) — categoria totalmente nova, cobrindo 24 CWEs relacionadas a tratamento inadequado de erros, falhas lógicas e sistemas que "falham abertos".

---

A lista completa do OWASP Top 10 (2025)

A seguir, cada vulnerabilidade é detalhada com definição, exemplo real, prevenção e detecção via DAST.

1. A01:2025 — Broken Access Control (Controle de Acesso Quebrado)

O que é: Falhas no controle de acesso permitem que usuários executem ações fora de suas permissões. Isso inclui acessar dados de outros usuários, modificar registros alheios, escalar privilégios ou acessar endpoints administrativos sem autorização. Na edição 2025, essa categoria absorveu o SSRF (Server-Side Request Forgery), já que forçar requisições internas é, em essência, um desvio de controle de acesso.

Exemplo real: Um usuário comum altera o parâmetro userId=123 para userId=456 na URL e consegue visualizar os dados de outro cliente. Esse tipo de falha, conhecido como IDOR (Insecure Direct Object Reference), é extremamente frequente.

Exemplo de SSRF (agora parte de A01): Uma funcionalidade de "preview de URL" aceita o input http://169.254.169.254/latest/meta-data/iam/security-credentials/ e retorna as credenciais IAM da instância EC2.

Como prevenir:

• Implementar controle de acesso no lado do servidor, nunca apenas no frontend.
• Adotar o princípio de negação por padrão: negar tudo que não for explicitamente permitido.
• Validar e sanitizar todas as URLs em requisições server-side (prevenção de SSRF).
• Bloquear requisições para ranges de IP privados (10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16).
• Registrar e monitorar falhas de controle de acesso em logs centralizados.

Como o DAST detecta: O módulo WebAppScan executa testes autenticados com diferentes perfis de usuário, manipulando parâmetros de referência direta (IDs, GUIDs) e tentando acessar recursos de outros perfis. Para SSRF, injeta payloads direcionados a serviços internos e endpoints de metadados cloud. A evidência inclui a requisição manipulada e a resposta do servidor contendo dados não autorizados.

---

2. A02:2025 — Security Misconfiguration (Configuração Incorreta de Segurança)

O que é: A vulnerabilidade mais frequente na prática — e por isso subiu de #5 para #2 na edição 2025. Inclui configurações padrão inseguras, serviços desnecessários habilitados, headers de segurança ausentes, mensagens de erro detalhadas expostas ao usuário, permissões excessivamente abertas e falhas de configuração em cloud (S3 buckets públicos, security groups abertos).

Exemplo real: Uma aplicação em produção mantém o modo debug ativado, expondo stack traces completos com nomes de tabelas, versões de framework e caminhos internos do servidor sempre que ocorre um erro.

Como prevenir:

• Implementar um processo de hardening repetível e automatizado.
• Remover funcionalidades, componentes e documentação desnecessários.
• Configurar headers de segurança (X-Content-Type-Options, X-Frame-Options, CSP, Strict-Transport-Security).
• Revisar configurações de cloud (S3 buckets, security groups, IAM policies) periodicamente.
• Utilizar Infrastructure as Code (IaC) com validação de segurança automatizada.

Como o DAST detecta: O WebAppScan verifica sistematicamente a presença de headers de segurança, detecta páginas de erro com informações sensíveis, identifica diretórios expostos (directory listing), arquivos de configuração acessíveis e serviços administrativos sem autenticação. A evidência inclui cada header ausente e a resposta completa contendo informações vazadas.

---

3. A03:2025 — Software Supply Chain Failures (Falhas na Cadeia de Suprimentos de Software)

O que é: Está é a grande novidade da edição 2025. A categoria evolui a antiga A06:2021 (Vulnerable and Outdated Components) e amplia significativamente o escopo para cobrir toda a cadeia de suprimentos de software: dependências vulneráveis, pacotes maliciosos, pipelines CI/CD comprometidos, falta de verificação de integridade e ausência de SBOM (Software Bill of Materials).

Ataques como Log4Shell (CVE-2021-44228), SolarWinds Orion e Codecov demonstraram que comprometer um único elo da cadeia pode afetar milhares de organizações simultaneamente. Entender os riscos da cadeia de suprimentos é fundamental para prevenir esse tipo de ataque.

Exemplo real: Uma organização utiliza a biblioteca Apache Log4j 2.14.1, vulnerável ao Log4Shell (CVE-2021-44228), permitindo execução remota de código. Em outro cenário, um pacote npm popular é comprometido com código malicioso que exfiltra variáveis de ambiente (tokens, credenciais) durante o build.

Como prevenir:

• Manter um SBOM atualizado de todos os componentes e suas versões.
• Monitorar continuamente fontes como NVD, GitHub Advisories e listas de segurança.
• Implementar verificação de integridade (checksums, assinaturas) em todos os artefatos.
• Garantir que pipelines CI/CD possuam segregação, controle de acesso e auditoria.
• Remover dependências não utilizadas e manter apenas versões suportadas.
• Adotar práticas de DevSecOps para integrar segurança ao ciclo de desenvolvimento.

Como o DAST detecta: O WebAppScan identifica versões de tecnologias expostas em headers de resposta, páginas de erro e fingerprints específicos. Complementarmente, o módulo VulScan realiza varreduras de infraestrutura que correlacionam versões de software com CVEs conhecidas, e o módulo Inventory mantém o inventário de ativos e componentes atualizado.

---

4. A04:2025 — Cryptographic Failures (Falhas Criptográficas)

O que é: Exposição de dados sensíveis por uso inadequado ou ausência de criptografia. Inclui transmissão de dados em texto claro, uso de algoritmos obsoletos (MD5, SHA-1, DES), certificados expirados e armazenamento de senhas sem hashing robusto.

Exemplo real: Uma aplicação de e-commerce transmite dados de cartão de crédito via HTTP em vez de HTTPS, permitindo que um atacante em posição de interceptação (man-in-the-middle) capture os dados completos da transação.

Como prevenir:

• Classificar dados processados e armazenados pela aplicação conforme sua sensibilidade.
• Aplicar TLS 1.2+ para dados em trânsito e criptografia AES-256 para dados em repouso.
• Usar funções de hash robustas para senhas (bcrypt, scrypt, Argon2).
• Eliminar cache de respostas que contenham dados sensíveis.

Como o DAST detecta: O WebAppScan verifica a configuração TLS do servidor, identifica certificados fracos ou expirados, detecta headers de segurança ausentes (Strict-Transport-Security) e localiza dados sensíveis em respostas HTTP não protegidas. A evidência técnica inclui o handshake TLS completo e os headers da resposta vulnerável.

---

5. A05:2025 — Injection (Injeção)

O que é: Ocorre quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta. Os tipos mais comuns são SQL Injection, Cross-Site Scripting (XSS), Command Injection e LDAP Injection.

Exemplo real: Um campo de login aceita a entrada ' OR 1=1 -- como nome de usuário, fazendo a consulta SQL retornar todos os registros da tabela de usuários e concedendo acesso administrativo ao atacante.

Como prevenir:

• Usar consultas parametrizadas (prepared statements) em vez de concatenação de strings.
• Aplicar validação de entrada no lado do servidor com listas de permissão (allowlists).
• Escapar caracteres especiais de acordo com o contexto de saída (HTML, SQL, OS).
• Implementar Content Security Policy (CSP) para mitigar XSS.

Como o DAST detecta: O WebAppScan injeta payloads específicos para cada tipo de injeção em todos os pontos de entrada da aplicação (parâmetros GET, POST, headers, cookies). A evidência apresenta a requisição com o payload injetado e a resposta do servidor confirmando a execução — por exemplo, mensagens de erro SQL ou reflexão de scripts no corpo da página — acompanhada do código de correção recomendado.

---

6. A06:2025 — Insecure Design (Design Inseguro)

O que é: Diferente de falhas de implementação, o design inseguro refere-se à ausência de controles de segurança na arquitetura da aplicação. É uma categoria que aborda a falta de modelagem de ameaças e padrões de design seguro (Security by Design) desde o início do desenvolvimento.

Exemplo real: Um sistema de recuperação de senha permite tentativas ilimitadas de resposta à pergunta secreta, sem bloqueio ou limite de taxa, possibilitando ataques de força bruta automatizados.

Como prevenir:

• Incorporar modelagem de ameaças (threat modeling) no ciclo de desenvolvimento.
• Adotar padrões de design seguro e bibliotecas de componentes testados.
• Implementar testes de abuso (abuse cases) além dos testes funcionais.
• Estabelecer limites de taxa e controles anti-automação em fluxos críticos.

Como o DAST detecta: O WebAppScan identifica a ausência de controles esperados, como falta de rate limiting em endpoints de autenticação, fluxos de recuperação de conta sem verificação adicional e funcionalidades críticas sem confirmação de identidade. O relatório inclui a sequência de requisições que demonstra a ausência do controle é a recomendação de design adequado.

---

7. A07:2025 — Authentication Failures (Falhas de Autenticação)

O que é: Falhas que permitem a um atacante comprometer senhas, tokens de sessão ou explorar implementações defeituosas de autenticação para assumir a identidade de outros usuários.

Exemplo real: Uma aplicação não invalida o token de sessão após o logout. Um atacante que obteve o token (via XSS ou interceptação) pode continuar usando-o indefinidamente para acessar a conta da vítima.

Como prevenir:

• Implementar autenticação multifator (MFA) para todos os acessos críticos.
• Nunca implantar a aplicação com credenciais padrão.
• Aplicar políticas de senha alinhadas às diretrizes NIST 800-63b.
• Invalidar sessões no lado do servidor após logout, inatividade e troca de senha.

Como o DAST detecta: O WebAppScan testa a robustez dos mecanismos de autenticação: verifica se tokens de sessão são invalidados após logout, se há proteção contra enumeração de usuários, se credenciais padrão estão presentes e se o mecanismo de bloqueio de conta funciona corretamente. A evidência técnica inclui as requisições com tokens expirados que ainda recebem respostas autenticadas.

---

8. A08:2025 — Software or Data Integrity Failures (Falhas de Integridade de Software ou Dados)

O que é: Falhas relacionadas a código e infraestrutura que não protegem contra violações de integridade. Inclui uso de bibliotecas de fontes não confiáveis, pipelines CI/CD inseguros e mecanismos de auto-atualização sem verificação de assinatura.

Exemplo real: Uma aplicação carrega bibliotecas JavaScript de um CDN sem usar Subresource Integrity (SRI). Se o CDN for comprometido, o atacante pode injetar código malicioso que será executado no navegador de todos os usuários.

Como prevenir:

• Usar assinaturas digitais para verificar a integridade de software e dados.
• Implementar Subresource Integrity (SRI) para recursos carregados de CDNs.
• Garantir que pipelines CI/CD possuam segregação, controle de acesso e auditoria.
• Não enviar dados serializados não assinados para clientes não confiáveis.

Como o DAST detecta: O WebAppScan analisa as respostas HTML em busca de recursos externos carregados sem atributos de integridade (SRI), verifica a presença de mecanismos de desserialização insegura e identifica endpoints que aceitam objetos serializados sem validação.

---

9. A09:2025 — Security Logging and Alerting Failures (Falhas de Registro e Alerta de Segurança)

O que é: Ausência ou insuficiência de logs de segurança e alertas (renomeada de "Monitoring" para "Alerting" na edição 2025), dificultando a detecção de ataques em andamento e a resposta a incidentes. A mudança de nome enfatiza que não basta monitorar — é preciso alertar e agir.

Exemplo real: Um atacante realiza milhares de tentativas de login com credenciais vazadas (credential stuffing) ao longo de semanas. A aplicação não registra tentativas de login falhas, e a equipe de segurança só descobre a violação quando clientes reportam acessos não autorizados.

Como prevenir:

• Registrar todas as tentativas de login, falhas de controle de acesso e erros de validação.
• Garantir que logs sejam gerados em formato padrão e consumíveis por SIEM.
• Implementar alertas automatizados para atividades suspeitas (não apenas dashboards passivos).
• Estabelecer um plano de resposta a incidentes e testá-lo regularmente.

Como o DAST detecta: O WebAppScan gera deliberadamente eventos que deveriam ser registrados (tentativas de acesso não autorizado, injeções, enumeração) e válida se a aplicação registra esses eventos de forma adequada. A ausência de evidência de bloqueio ou rate limiting após múltiplas tentativas maliciosas indica falha de monitoramento.

---

10. A10:2025 — Mishandling of Exceptional Conditions (Tratamento Inadequado de Condições Excepcionais)

O que é: Está é a segunda categoria nova da edição 2025, cobrindo 24 CWEs relacionadas ao tratamento inadequado de erros, condições de borda, falhas lógicas e sistemas que "falham abertos" (fail-open). Quando uma aplicação não lida corretamente com situações inesperadas, pode expor informações internas, ignorar validações de segurança ou conceder acessos indevidos.

Exemplo real: Um sistema de autenticação captura uma exceção durante a verificação de credenciais e, em vez de negar o acesso (fail-closed), assume que a autenticação foi bem-sucedida (fail-open), permitindo acesso sem credenciais válidas.

Outro exemplo: Uma API retorna stack traces detalhados quando recebe input malformado, expondo versões de framework, caminhos do servidor e estrutura interna do banco de dados.

Como prevenir:

• Adotar o princípio de fail-closed: na dúvida, negar acesso.
• Implementar tratamento de exceções abrangente que nunca exponha informações internas.
• Testar comportamento da aplicação com inputs inesperados, valores-limite e condições de erro.
• Validar que fluxos de autenticação e autorização mantêm a postura de segurança mesmo em cenários de falha.
• Usar mensagens de erro genéricas para o usuário, com detalhes apenas em logs internos.

Como o DAST detecta: O WebAppScan envia deliberadamente inputs malformados, valores fora de faixa e requisições com formatos inesperados para identificar respostas que exponham informações internas ou indiquem falha no tratamento de exceções. A evidência inclui as respostas com stack traces, mensagens de debug ou comportamento fail-open documentado.

---

Tabela resumo: OWASP Top 10 (2025)

---

Por que o OWASP Top 10 é essencial para programas de CTEM

O OWASP Top 10 não é apenas uma lista de referência — é o alicerce para a fase de descoberta e priorização dentro de um programa de Continuous Threat Exposure Management (CTEM). Ao mapear as vulnerabilidades da sua aplicação contra o OWASP Top 10, você estabelece uma linguagem comum entre equipes de desenvolvimento, segurança e gestão de risco.

A plataforma EcoTrust, como Plataforma de IA Agêntica para CTEM, integra os resultados do WebAppScan diretamente ao fluxo de gestão de exposições. Isso significa que cada vulnerabilidade detectada pelo DAST autenticado já nasce com:

• Evidência técnica completa: requisição vulnerável, resposta do servidor e prova de exploração.
• Código de correção recomendado: orientação prática para o time de desenvolvimento remediar a falha.
• Contexto de priorização: correlação com ativos críticos, score de risco e dados de inteligência de ameaças.

O módulo GVul consolida as vulnerabilidades de aplicações (WebAppScan), infraestrutura (VulScan) e superfície externa em uma visão unificada, permitindo que o analista priorize com base no risco real para o negócio.

---

OWASP Top 10 para LLMs: o novo projeto

Além do Top 10 tradicional para aplicações web, a OWASP lançou o OWASP Top 10 for Large Language Model Applications, focado nas vulnerabilidades específicas de aplicações que utilizam modelos de linguagem (LLMs). Categorias como Prompt Injection, Insecure Output Handling e Supply Chain Vulnerabilities ganharam destaque à medida que organizações integram IA generativa aos seus sistemas.

Se sua organização utiliza LLMs em produção, esse projeto complementar merece atenção especial dentro do programa de CTEM.

---

Como começar a testar o OWASP Top 10 na sua organização

A abordagem mais eficaz combina testes DAST autenticados com gestão contínua:

1. Inventarie suas aplicações web. Identifique todas as aplicações expostas e internas, incluindo APIs REST e GraphQL.
2. Configure scans autenticados. Testes sem autenticação cobrem apenas a superfície pública. O WebAppScan executa testes autenticados que acessam áreas protegidas, onde residem as vulnerabilidades mais críticas.
3. Análise as evidências. Cada finding inclui a requisição/resposta vulnerável e o código de correção, eliminando falsos positivos e acelerando a triagem.
4. Priorize pela exposição real. Use o contexto de risco do CTEM para focar nas vulnerabilidades que representam maior impacto para o negócio.
5. Valide a remediação. Re-execute os scans após a correção para confirmar que a vulnerabilidade foi eliminada.

Agende uma demonstração do WebAppScan e veja como o DAST autenticado detecta as vulnerabilidades do OWASP Top 10 com evidência completa.

---

FAQ — Perguntas frequentes sobre o OWASP Top 10

O OWASP Top 10 é um padrão de segurança? Não oficialmente. O OWASP Top 10 é um documento de conscientização amplamente adotado como referência por regulações e frameworks como PCI DSS, ISO 27001 e NIST. Muitas organizações o utilizam como requisito mínimo em auditorias de segurança de aplicações.

O que mudou na versão 2025 em relação à 2021? A edição 2025 trouxe duas novas categorias: Software Supply Chain Failures (A03) e Mishandling of Exceptional Conditions (A10). Security Misconfiguration subiu de #5 para #2. SSRF deixou de ser categoria independente e foi incorporada ao Broken Access Control (A01). A antiga A06 (Vulnerable Components) evoluiu para a categoria mais abrangente de Supply Chain Failures.

O que são Software Supply Chain Failures? São falhas na cadeia de suprimentos de software: dependências com vulnerabilidades conhecidas, pacotes maliciosos em repositórios públicos, pipelines CI/CD comprometidos e falta de SBOM. Casos como Log4Shell e SolarWinds motivaram a criação dessa categoria.

O que é Mishandling of Exceptional Conditions? É a nova A10:2025, cobrindo situações em que a aplicação não lida corretamente com erros, condições de borda e exceções. O risco principal é o comportamento fail-open — quando um erro faz o sistema conceder acesso em vez de negar.

DAST é suficiente para cobrir todo o OWASP Top 10? DAST autenticado cobre a maioria das categorias com alta eficácia, especialmente A01, A02, A04, A05, A07 e A10. Para cobertura completa de A03 (Supply Chain), recomenda-se combinar com análise de composição de software (SCA) e SBOM. Para A06 (Insecure Design), revisão de arquitetura é essencial.

Com que frequência devo testar minhas aplicações? Em um programa de CTEM, os testes devem ser contínuos. No mínimo, execute scans completos a cada sprint ou release, e scans incrementais após cada deploy. Aplicações críticas devem ser testadas semanalmente.

O OWASP Top 10 cobre APIs? O OWASP Top 10 principal foca em aplicações web. Para APIs, a OWASP mantém uma lista separada: o OWASP API Security Top 10, que aborda vulnerabilidades específicas de APIs REST e GraphQL. O WebAppScan testa ambos os cenários.

Como priorizar a remediação das vulnerabilidades encontradas? Use uma combinação de severidade técnica (CVSS), probabilidade de exploração (EPSS) e impacto no negócio. A plataforma EcoTrust automatiza essa priorização correlacionando dados de múltiplas fontes dentro do fluxo de CTEM.

---

Conclusão

O OWASP Top 10 2025 reflete um cenário de ameaças em evolução, onde a cadeia de suprimentos de software e o tratamento inadequado de exceções se somam às vulnerabilidades clássicas como controle de acesso quebrado e injeção. Para analistas de segurança, dominar cada categoria significa saber exatamente o que procurar, como validar e como orientar a remediação.

Testes DAST autenticados, como os executados pelo módulo WebAppScan da EcoTrust, transformam o OWASP Top 10 de uma lista teórica em achados concretos com evidência técnica e código de correção. Integrados a um programa de CTEM, esses resultados alimentam um ciclo contínuo de descoberta, priorização e validação de exposições.

Conheça o WebAppScan e proteja suas aplicações contra as vulnerabilidades do OWASP Top 10.