Top 10 OWASP 2025: as maiores vulnerabilidades de segurança e como evitar

O OWASP Top 10 é a lista das dez categorias de risco mais críticas em segurança de aplicações web, publicada pela OWASP (Open Web Application Security Project), organização global sem fins lucrativos dedicada a melhorar a segurança de software. A edição mais recente é a OWASP Top 10:2025, a oitava da série, construída a partir de dados de cerca de 2,8 milhões de aplicações. Neste guia você vê cada categoria com exemplo, como evitar, o que mudou em relação à edição de 2021 e um exemplo de código.

Antes de começar, uma observação: a lista é um guia de conscientização, não um checklist completo. Ela ajuda a priorizar, mas segurança exige processo contínuo.

O que mudou da edição 2021 para a 2025

• Duas categorias novas: Software Supply Chain Failures (A03), que amplia o antigo "componentes vulneráveis e desatualizados", e Mishandling of Exceptional Conditions (A10), sobre tratamento incorreto de erros e condições excepcionais.
• SSRF foi incorporado ao A01 (Broken Access Control), deixando de ser uma categoria própria.
• Security Misconfiguration subiu da 5ª para a 2ª posição.
• Injection caiu da 3ª para a 5ª posição, e Cryptographic Failures da 2ª para a 4ª.
• Dois nomes mudaram: "Authentication Failures" (antes "Identification and Authentication Failures") e "Logging and Alerting Failures" (antes "Logging and Monitoring"), para dar ênfase ao alerta.

Resumo do Top 10:2025

A01:2025 – Broken Access Control (Controle de acesso quebrado)

Ocorre quando o sistema falha em restringir o que cada usuário pode fazer. Continua em primeiro lugar. Nesta edição, o SSRF (Server-Side Request Forgery, em que o servidor é induzido a fazer requisições a destinos internos) passou a fazer parte desta categoria.

Exemplo: um usuário comum acessa /admin apenas digitando a URL, ou altera /pedido/1001 para /pedido/1002 e vê o pedido de outra pessoa (problema conhecido como IDOR).

Como evitar:

• Negue por padrão e verifique a permissão no servidor, em cada requisição.
• Confira se o recurso pertence ao usuário autenticado, não só se ele está logado.
• Em URLs informadas pelo usuário, valide o destino contra uma lista permitida (para evitar SSRF) e bloqueie endereços internos.

A02:2025 – Security Misconfiguration (Configuração incorreta de segurança)

Configurações padrão, serviços desnecessários ativos, mensagens de erro detalhadas e permissões amplas demais. Subiu para a 2ª posição porque cada vez mais comportamento das aplicações depende de configuração (nuvem, contêineres, infrastructure as code).

Exemplo: um bucket de armazenamento público com backups, ou um painel administrativo com a senha de fábrica.

Como evitar: use configuração mínima e reproduzível, remova recursos e contas não usados, desative detalhes de erro em produção e revise as configurações de forma automatizada.

A03:2025 – Software Supply Chain Failures (Falhas na cadeia de suprimentos de software)

Amplia o antigo item de componentes vulneráveis. Agora cobre toda a cadeia: dependências, ferramentas de build, pipelines de CI/CD e distribuição. Um pacote comprometido ou um build adulterado atinge todos que o usam.

Exemplo: uma biblioteca popular recebe uma atualização maliciosa e sua aplicação a instala automaticamente.

Como evitar:

• Mantenha um inventário das dependências (SBOM) e atualize com critério.
• Fixe versões e use arquivos de bloqueio (lockfiles).
• Use ferramentas de análise de composição de software (SCA), como o OWASP Dependency-Check.
• Proteja o pipeline: acesso restrito, revisão de código e segredos fora do repositório.

A04:2025 – Cryptographic Failures (Falhas criptográficas)

Dados sensíveis sem proteção adequada, em trânsito ou armazenados: ausência de HTTPS, algoritmos fracos, chaves expostas ou senhas guardadas em texto puro.

Como evitar:

• Use TLS em toda a comunicação.
• Guarde senhas com um algoritmo de hash próprio para isso (Argon2id, bcrypt ou scrypt), nunca com MD5 ou SHA-1 puros, e nunca com criptografia reversível.
• Cifre dados em repouso com algoritmos modernos, como AES-256-GCM, e proteja as chaves.
• Não guarde dados sensíveis que você não precisa.

Para criar senhas fortes e aleatórias, use o gerador de senhas e leia como criar uma senha forte.

A05:2025 – Injection (Injeção)

Acontece quando dados não confiáveis são interpretados como comando ou consulta (SQL, NoSQL, comandos do sistema operacional, LDAP e também XSS, que é a injeção de script no navegador).

// VULNERÁVEL: a entrada é concatenada na consulta
db.query("SELECT * FROM usuarios WHERE email = '" + email + "'");
// Entrada: ' OR '1'='1   → retorna todos os usuários

// CORRETO: consulta parametrizada
db.query("SELECT * FROM usuarios WHERE email = $1", [email]);

Como evitar: use consultas parametrizadas ou ORM, valide a entrada por lista permitida, escape a saída conforme o contexto (HTML, JavaScript, URL) e aplique o princípio do menor privilégio na conta do banco.

A06:2025 – Insecure Design (Design inseguro)

Falhas que nascem no projeto e não podem ser corrigidas só com código bem escrito, porque o controle nunca foi pensado.

Exemplo: um fluxo de recuperação de senha que responde "e-mail não encontrado", permitindo descobrir quais e-mails têm conta, ou um sistema de cupons sem limite de uso.

Como evitar: faça modelagem de ameaças (como o método STRIDE) nas fases iniciais, escreva requisitos de segurança e casos de abuso, e adote secure by design.

A07:2025 – Authentication Failures (Falhas de autenticação)

Fraquezas na forma de confirmar a identidade: senhas fracas permitidas, ausência de limite de tentativas, sessões que não expiram ou tokens previsíveis.

Como evitar:

• Ofereça autenticação multifator (MFA).
• Limite tentativas de login e verifique senhas contra listas de senhas vazadas.
• Gere identificadores de sessão aleatórios e invalide-os no logout e após inatividade.
• Não exponha o identificador de sessão na URL.

A08:2025 – Software or Data Integrity Failures (Falhas de integridade de software ou dados)

Confiar em código ou dados sem verificar sua integridade: atualizações sem assinatura, dados serializados vindos do cliente e scripts de terceiros carregados sem checagem.

Como evitar: verifique assinaturas digitais, use Subresource Integrity (atributo integrity) em scripts externos, não desserialize dados não confiáveis e revalide no servidor tudo o que vem do cliente.

A09:2025 – Security Logging and Alerting Failures (Falhas de registro e alerta)

Sem registro adequado e sem alertas, ataques passam despercebidos por meses. O nome passou a destacar o alerta: registrar não basta se ninguém é avisado.

Como evitar:

• Registre logins (com sucesso e falha), erros de acesso e operações sensíveis.
• Nunca grave senhas, tokens ou dados de cartão nos logs.
• Centralize os logs, use um SIEM e configure alertas para comportamento suspeito.
• Tenha um plano de resposta a incidentes.

A10:2025 – Mishandling of Exceptional Conditions (Tratamento incorreto de condições excepcionais)

Categoria nova. Reúne falhas no tratamento de erros e situações inesperadas: exceções ignoradas, mensagens de erro que revelam detalhes internos e sistemas que, ao falhar, ficam abertos (fail open) em vez de negar o acesso.

// RUIM: se a verificação falhar, o acesso é liberado
try {
  autorizado = await verificarPermissao(usuario, recurso);
} catch (e) {
  autorizado = true;   // fail open
}

// CERTO: em caso de erro, negue
try {
  autorizado = await verificarPermissao(usuario, recurso);
} catch (e) {
  log.error(e);
  autorizado = false;  // fail closed
}

Como evitar: trate os erros de forma centralizada, falhe de forma segura (negando), exiba mensagens genéricas ao usuário e guarde os detalhes só nos logs, e teste cenários de falha e entradas inesperadas.

Como usar o Top 10 na prática

• Treinamento: use a lista como base para ensinar a equipe de desenvolvimento.
• Revisão de código e testes: inclua verificações de cada categoria nas revisões e em ferramentas de análise (SAST e DAST).
• Requisitos: transforme as categorias em requisitos de segurança do projeto.
• Para ir além: a OWASP também mantém o ASVS (padrão de verificação de segurança) e o Cheat Sheet Series, com orientações detalhadas.

Perguntas frequentes

Com que frequência a lista é atualizada?

Em intervalos de alguns anos. As edições anteriores foram publicadas em 2017 e 2021, e a atual é a de 2025.

O que aconteceu com o Top 10:2021?

Continua válido como referência histórica, e muitos materiais e ferramentas ainda o usam. A maioria das categorias se mantém, com nomes e posições diferentes.

O SSRF deixou de ser importante?

Não. Ele foi incorporado ao A01 (Broken Access Control), e continua sendo um risco relevante, em especial em aplicações em nuvem.

O Top 10 vale para APIs?

Sim, e a OWASP também mantém uma lista específica, o API Security Top 10.

Ferramenta relacionada: Gerador de Senhas, para criar senhas fortes e aleatórias sem enviar nada para a internet.