OWASP Top 10 explicado: os riscos de segurança mais críticos em aplicações web

Se você trabalha em qualquer área próxima da segurança de aplicações, já ouviu falar do OWASP Top 10. Ele é citado em apresentações para a diretoria, escrito em requisitos de conformidade e referenciado em quase todo questionário de segurança que uma empresa de software receberá. Apesar de toda essa visibilidade, ele também é frequentemente mal compreendido — tratado como uma certificação a ser aprovada, em vez do que realmente é: um vocabulário compartilhado para os riscos de segurança em aplicações web mais críticos que as equipes enfrentam hoje.

Este guia percorre o OWASP Top 10:2025 em ordem, uma categoria de cada vez. Para cada uma, explicamos o que significa, um exemplo concreto de como ela dá errado e como preveni-la ou detectá-la. Em seguida, vemos como incorporar esses riscos ao seu ciclo de vida de desenvolvimento de software para que sejam capturados cedo — e não após um incidente. O objetivo é prático: ao final, você deve ser capaz de explicar cada risco a um engenheiro ou a uma parte interessada e saber onde ele se encaixa na sua estratégia de testes.

O que é a OWASP?

A OWASP — o Open Worldwide Application Security Project — é uma fundação sem fins lucrativos dedicada a melhorar a segurança de software. É orientada pela comunidade e neutra em relação a fornecedores, o que é grande parte do motivo pelo qual sua orientação tem peso: os materiais são produzidos por profissionais, disponíveis gratuitamente e não vinculados a nenhum produto comercial.

A OWASP publica uma ampla gama de recursos — guias de teste, cheat sheets, referências de codificação segura e ferramentas —, mas seu resultado mais conhecido, de longe, é o OWASP Top 10. Lançado pela primeira vez em 2003 e atualizado periodicamente, o Top 10 é um documento de consenso que classifica os riscos de segurança em aplicações web mais significativos com base em dados do setor, combinados com uma pesquisa da comunidade para capturar ameaças emergentes que só os dados brutos poderiam não revelar. Quando alguém diz que um produto "cobre o OWASP Top 10", quer dizer que ele aborda essas dez amplas categorias de risco.

Uma nuance importante: cada item é uma categoria, não uma única vulnerabilidade. "Injection", por exemplo, abrange SQL injection, command injection e vários outros tipos. Essa estrutura é deliberada — mantém a lista estável e conceitual, em vez de um alvo móvel de CVEs específicos.

O OWASP Top 10:2025

Abaixo estão as dez categorias do OWASP Top 10:2025, em sua ordem oficial. A classificação reflete uma combinação de com que frequência cada fraqueza aparece, quão explorável ela tende a ser e o potencial impacto para o negócio. Uma observação antes de começarmos: o OWASP Top 10 é revisado periodicamente à medida que a forma como construímos e atacamos software muda, e as categorias abaixo refletem a versão de 2025 — a edição atual, e a atualização da antiga lista de 2021.

A01:2025 — Broken Access Control

O controle de acesso impõe o que um usuário autenticado tem permissão de fazer. Quando essas verificações estão ausentes, incompletas ou aplicadas apenas na interface, os usuários podem alcançar dados e ações que deveriam estar fora de alcance. Esta categoria ocupa o primeiro lugar novamente em 2025 porque a lógica de autorização é enganosamente difícil de acertar em cada endpoint.

Exemplo: Uma API retorna um pedido por ID em /api/orders/1043. Um usuário altera o ID para 1044 e vê o pedido de outra pessoa — uma clássica referência insegura e direta a objeto (IDOR). O servidor autenticou o usuário, mas nunca verificou se este usuário é dono daquele pedido.

Como preveni-lo e detectá-lo: Negue por padrão e imponha as decisões de acesso no lado do servidor em cada requisição, em vez de confiar no cliente. Centralize a lógica de autorização em vez de espalhar verificações improvisadas. Escreva testes que tentem acesso entre contas e use testes em tempo de execução para sondar endpoints com identificadores e papéis manipulados. Registre em log as falhas de controle de acesso para que tentativas repetidas fiquem visíveis.

A02:2025 — Security Misconfiguration

A configuração incorreta abrange definições padrão inseguras, mensagens de erro verbosas, recursos desnecessários deixados habilitados, armazenamento em nuvem aberto e falta de hardening. Ela subiu para a segunda posição em 2025, refletindo o quanto do risco moderno agora reside na configuração, e não no código — à medida que as stacks se tornam mais complexas, com contêineres, orquestração e serviços gerenciados, a superfície para uma configuração errada cresce junto.

Exemplo: Um bucket de armazenamento em nuvem é deixado publicamente legível, ou uma aplicação é entregue com uma conta e senha de administrador padrão ainda ativas, ou um stack trace expõe caminhos internos e versões de bibliotecas aos usuários finais. Uma configuração de fetch permissiva pode até abrir a porta para server-side request forgery (SSRF), na qual uma aplicação é coagida a chamar um endpoint de metadados interno.

Como preveni-lo e detectá-lo: Faça o hardening de forma sistemática, remova componentes e recursos não utilizados e aplique a mesma baseline segura em cada ambiente, para que o staging corresponda à produção. Automatize verificações de configuração no seu pipeline e faça a varredura dos ambientes em execução. Os testes dinâmicos são bem adequados para capturar mensagens de erro expostas, páginas padrão e cabeçalhos permissivos em tempo de execução.

A03:2025 — Software Supply Chain Failures

Em 2025, a categoria anteriormente conhecida como "Vulnerable and Outdated Components" (componentes vulneráveis e desatualizados) foi ampliada e renomeada para Software Supply Chain Failures (falhas na cadeia de suprimentos de software) — um reconhecimento de que o risco é muito mais amplo do que uma única biblioteca defasada. As aplicações modernas são montadas a partir de dependências de código aberto, mas também são construídas por pipelines e entregues por meio de canais de distribuição. Uma falha em qualquer ponto dessa cadeia — os componentes que você incorpora, os sistemas que os montam ou os canais que os distribuem — torna-se problema seu.

Exemplo: Uma aplicação depende de uma biblioteca amplamente usada com um CVE crítico publicado que a equipe nunca atualizou, e um atacante explora a falha conhecida. Ou uma dependência de build comprometida injeta código malicioso durante o CI, de modo que a adulteração acontece a montante de qualquer revisão de código — sem necessidade de pesquisa inovadora, apenas um elo desprotegido na cadeia.

Como preveni-lo e detectá-lo: Mantenha um inventário das suas dependências (um software bill of materials ajuda) e monitore-as continuamente em relação a bancos de dados de vulnerabilidades. A software composition analysis automatiza isso — sinalizando componentes vulneráveis e desatualizados, incluindo dependências transitivas que você não adicionou diretamente. Estenda esse escrutínio ao próprio pipeline: fixe e verifique as ferramentas de build, proteja seus sistemas de CI/CD e trate o caminho de build e distribuição como parte da sua superfície de ataque.

A04:2025 — Cryptographic Failures

Às vezes enquadrada como "Sensitive Data Exposure" (exposição de dados sensíveis), esta categoria trata de falhas na forma como os dados são protegidos em trânsito e em repouso — criptografia fraca ou ausente, gestão de chaves deficiente ou dados sensíveis que simplesmente não deveriam ter sido armazenados. A falha é a causa raiz; a exposição é a consequência.

Exemplo: Uma aplicação armazena senhas usando um hash rápido e sem salt, ou transmite tokens de sessão por HTTP em texto puro em um salto interno. Quando um atacante obtém uma cópia do banco de dados ou intercepta o tráfego, os dados são trivialmente legíveis.

Como preveni-lo e detectá-lo: Classifique quais dados você possui e minimize o que você guarda. Imponha criptografia forte de transporte em todos os lugares, use algoritmos modernos e bem avaliados e faça o hash de senhas com uma função lenta, com salt e projetada para esse fim. Gerencie as chaves adequadamente e faça a rotação delas. Ferramentas de varredura e revisões de configuração podem sinalizar protocolos fracos, segredos codificados diretamente no código e cifras obsoletas.

A05:2025 — Injection

A injeção acontece quando uma entrada não confiável é interpretada como parte de um comando ou consulta. O SQL injection é o arquétipo, mas a categoria também abrange OS command injection, LDAP injection e cross-site scripting (XSS).

Exemplo: Um formulário de login constrói uma consulta SQL concatenando o nome de usuário diretamente na instrução. Um atacante envia ' OR '1'='1 e ignora a autenticação, ou extrai a tabela de usuários inteira.

Como preveni-lo e detectá-lo: Use consultas parametrizadas e prepared statements para que os dados nunca possam ser executados como código. Valide e, quando apropriado, codifique a entrada com base no contexto de destino. A análise estática é particularmente eficaz aqui — ela rastreia a entrada não confiável da origem ao destino (source to sink) e sinaliza a construção insegura de consultas e o tratamento de saída antes de o código ser entregue.

A06:2025 — Insecure Design

Esta categoria desloca a atenção a montante, para falhas na arquitetura e no design, em vez de bugs de implementação. Um recurso perfeitamente codificado ainda pode ser inseguro se o design nunca considerou o abuso. Você não consegue corrigir com patches a ausência de um controle de segurança que nunca foi projetado.

Exemplo: Um fluxo de redefinição de senha usa perguntas de segurança cujas respostas são facilmente encontradas online, sem limitação de taxa. O código funciona exatamente como foi escrito — o design simplesmente deixou de considerar como um atacante o abusaria.

Como preveni-lo e detectá-lo: Introduza o threat modeling cedo, quando alterar o design ainda é barato. Estabeleça padrões de design seguro e arquiteturas de referência que as equipes reutilizem. Escreva casos de abuso junto com as histórias de usuário e valide os limites da lógica de negócio (limites de taxa, tetos de transação, restrições de fluxo de trabalho) como requisitos de primeira classe, e não como reflexões posteriores.

A07:2025 — Authentication Failures

Renomeada em 2025 a partir de "Identification and Authentication Failures" (falhas de identificação e autenticação), esta categoria abrange fraquezas em confirmar quem é um usuário e manter essa identidade de forma segura — políticas de senha fracas, exposição a credential stuffing, gestão de sessão deficiente e implementações falhas de múltiplos fatores.

Exemplo: Uma aplicação permite tentativas de login ilimitadas, sem bloqueio ou throttling, deixando um atacante executar listas de credential stuffing contra ela. Ou os tokens de sessão não passam por rotação após o login, deixando-os vulneráveis a fixação.

Como preveni-lo e detectá-lo: Ofereça suporte e incentive a autenticação multifator, imponha proteção contra adivinhação automatizada (limitação de taxa, bloqueios, verificação de senhas vazadas) e gerencie as sessões com cuidado — faça a rotação dos identificadores no login, defina atributos seguros nos cookies e expire as sessões de forma apropriada. Prefira frameworks de autenticação bem testados a criar o seu próprio.

A08:2025 — Software or Data Integrity Failures

Esta categoria trata de código e infraestrutura que deixam de se proteger contra violações de integridade — confiar em plugins, bibliotecas ou atualizações de fontes sem verificar se não foram adulterados. Ela surgiu diretamente de ataques de cadeia de suprimentos de grande repercussão e fica próxima do A03, mas foca especificamente na verificação da integridade, em vez da amplitude da cadeia de suprimentos.

Exemplo: Um pipeline de build baixa uma atualização por um canal não verificado, ou uma aplicação desserializa dados não confiáveis sem verificações. Um artefato comprometido ou malicioso flui diretamente para a produção porque nada verificou sua integridade.

Como preveni-lo e detectá-lo: Use pacotes assinados e verifique as assinaturas, fixe as dependências em versões conhecidas como boas e proteja seu pipeline de CI/CD para que as etapas de build e implantação não possam ser adulteradas. Evite a desserialização insegura de dados não confiáveis. Trate seu sistema de build como infraestrutura de produção, que merece o mesmo escrutínio que sua aplicação.

A09:2025 — Security Logging and Alerting Failures

Você não consegue responder ao que não consegue ver. Reformulada em 2025 como Security Logging and Alerting Failures (falhas de registro de logs e alertas de segurança), esta categoria trata de registro de logs, alertas e da resposta que deveria segui-los, todos insuficientes — a lacuna que permite que violações passem despercebidas por semanas ou meses. Ela raramente causa o comprometimento inicial, mas piora drasticamente o resultado.

Exemplo: Uma série de logins malsucedidos seguida de um bem-sucedido a partir de um local incomum não gera nenhum alerta, e os eventos de autenticação não são registrados de forma alguma. A intrusão só é descoberta quando os dados aparecem em outro lugar.

Como preveni-lo e detectá-lo: Registre em log os eventos relevantes para a segurança — logins, falhas de controle de acesso, transações de alto valor — com contexto suficiente para investigar, e garanta que os logs sejam resistentes a adulteração e coletados de forma centralizada. Defina alertas para padrões suspeitos e ensaie um plano de resposta a incidentes para que a detecção realmente leve à ação. Tenha cuidado para não registrar em log os próprios dados sensíveis.

A10:2025 — Mishandling of Exceptional Conditions

Nova em 2025, esta categoria trata de como as aplicações se comportam quando algo dá errado — tratamento inadequado de erros, erros lógicos em casos extremos e o hábito perigoso de falhar de forma aberta em vez de fechada. Quando surge uma condição inesperada e o código toma o caminho inseguro por padrão, um atacante pode desencadear deliberadamente essas condições para escapar dos controles.

Exemplo: Uma verificação de autorização lança uma exceção quando um serviço a jusante está inacessível, e o bloco catch registra o erro em log, mas deixa a requisição prosseguir — de modo que um usuário alcança um recurso protegido precisamente porque algo quebrou. Respostas de erro verbosas também podem vazar stack traces e detalhes internos que ajudam um atacante a mapear o sistema.

Como preveni-lo e detectá-lo: Projete para a falha: decida explicitamente o que deve acontecer quando uma verificação não puder ser concluída e faça do padrão o resultado seguro. Trate as exceções deliberadamente, em vez de engoli-las, retorne mensagens de erro genéricas aos usuários enquanto registra os detalhes internamente, e teste os caminhos infelizes — entrada malformada, timeouts, indisponibilidade de dependências — e não apenas os caminhos felizes.

Como abordar o OWASP Top 10 no seu SDLC

Ler a lista é a parte fácil. O trabalho de verdade é construir defesas que capturem esses riscos continuamente, sem reduzir a engenharia a passos de tartaruga. Nenhuma técnica isolada cobre as dez categorias, então a resposta prática é combinar camadas de controles complementares ao longo do ciclo de vida de desenvolvimento — deslocando a segurança para a esquerda (shift left), de modo que os problemas sejam encontrados enquanto ainda são baratos de corrigir.

O design seguro vem primeiro. O Insecure Design (A06) existe justamente porque as ferramentas não conseguem adaptar retroativamente um controle que nunca foi concebido — e o mesmo vale para o Mishandling of Exceptional Conditions (A10), em que falhar com segurança é uma decisão de design. O threat modeling, os casos de abuso e os padrões seguros reutilizáveis capturam classes inteiras de risco antes que uma linha de código seja escrita. Este é o investimento de maior alavancagem que você pode fazer.

A análise estática (SAST) cobre falhas em nível de código. A Injection (A05), muitos erros de controle de acesso (A01), fraquezas criptográficas (A04) e o tratamento inseguro de erros (A10) aparecem como padrões identificáveis no código-fonte. O SAST rastreia a entrada não confiável da origem ao destino (source to sink) e sinaliza a construção insegura de consultas, o uso fraco de criptografia e segredos codificados diretamente no código — idealmente de forma inline no pull request do desenvolvedor, onde o contexto está mais fresco.

A software composition e a análise da cadeia de suprimentos (SCA) cobrem suas dependências — e agora mais do que nunca. Com as Software Supply Chain Failures (A03) ampliadas em 2025 e as Software or Data Integrity Failures (A08) ao seu lado, a cadeia de suprimentos é uma das partes que mais crescem na lista. O SCA inventaria suas dependências de código aberto, incluindo as transitivas, e as compara continuamente com vulnerabilidades conhecidas para que um componente arriscado seja capturado antes do merge. Estender essa visibilidade às ferramentas de build e à integridade do pipeline é o que faz a diferença contra os ataques modernos de cadeia de suprimentos.

A análise dinâmica (DAST) cobre o comportamento em tempo de execução. A Security Misconfiguration (A02), as lacunas de autenticação (A07), as falhas de controle de acesso (A01) e o tratamento de condições excepcionais (A10) — incluindo problemas como o SSRF, que surgem por meio de configuração permissiva — muitas vezes só se revelam em uma aplicação em execução. O DAST exercita a aplicação implantada da forma como um atacante faria, revelando mensagens de erro expostas, configurações permissivas e autorização quebrada que as visões estáticas não captam.

O registro de logs e os alertas fecham o ciclo. As Security Logging and Alerting Failures (A09) são um lembrete de que a prevenção nunca é perfeita. Instrumente eventos relevantes para a segurança, centralize e proteja seus logs e alerte sobre padrões suspeitos, de modo que, quando algo escapar, você o veja em horas, e não em meses.

Costurar tudo isso manualmente — ferramentas separadas, dashboards separados, filas de triagem separadas — é onde muitos programas empacam. É aqui que uma camada de segurança consolidada conquista seu lugar. A Rainforest reúne SAST, SCA e DAST no seu fluxo de trabalho existente, mapeando os achados de volta para categorias como o OWASP Top 10 e encontrando os desenvolvedores no pull request, em vez de em um relatório trimestral. O resultado é cobertura de toda a lista sem pedir que os engenheiros se tornem especialistas de segurança em tempo integral.

Se você está construindo ou amadurecendo um programa de segurança de aplicações, comece mapeando sua cobertura atual em relação a essas dez categorias e, em seguida, feche as lacunas com testes automatizados no seu pipeline. Para ver como uma abordagem unificada se encaixa no seu SDLC, explore a plataforma de teste de segurança de aplicações da Rainforest — ou leia nosso guia complementar, O que é segurança de aplicações, para o panorama mais amplo.