OWASP Top 10 2025: cada risco explicado com exemplos

O que é o OWASP Top 10?

O que é o OWASP Top 10? O OWASP Top 10 é um documento padrão de conscientização que classifica os dez riscos de segurança mais críticos para aplicações web. É publicado pelo Open Worldwide Application Security Project, uma organização sem fins lucrativos que produz recursos de segurança gratuitos, e é reconstruído aproximadamente a cada três ou quatro anos a partir de dados contribuídos sobre aplicações do mundo real.

A palavra importante é riscos, não vulnerabilidades. Cada entrada é uma categoria, não um único bug. "Injection" abrange SQL injection, cross-site scripting, command injection e mais, todos agrupados porque compartilham uma causa raiz: entrada não confiável chegando a um interpretador. Esse agrupamento é o que torna a lista útil. Você não memoriza dez mil bugs, você entende dez padrões e reconhece suas variações.

O OWASP monta a classificação a partir de duas fontes. A maioria das categorias vem de dados: fornecedores de segurança e empresas de teste enviam achados mapeados para identificadores Common Weakness Enumeration (CWE) em centenas de milhares de aplicações, e o OWASP calcula com que frequência cada classe de fraqueza aparece e quanto impacto ela carrega. Um número menor de categorias vem de uma pesquisa do setor, que capta riscos emergentes que os scanners automatizados perdem porque as ferramentas ainda não conseguem detectá-los bem. Insecure Design entrou na lista dessa forma.

A lista importa porque se tornou a linguagem comum da segurança de aplicações. Frameworks de conformidade a referenciam, descrições de vagas a esperam e triadores de bug bounty categorizam relatórios com ela. Conhecer o OWASP Top 10 é a base para qualquer pessoa que testa ou defende aplicações web, e é por isso que ele ancora todo curso sério de ataques web e aparece em quase todo currículo de certificação ofensiva.

A lista do OWASP Top 10 2025

Aqui está a classificação completa de 2025, conforme publicada no OWASP Top 10 2025 oficial. Cada risco abaixo inclui o que ele é, um exemplo concreto e um laboratório onde você pode explorá-lo por conta própria. Percorra-os em ordem na primeira vez; a classificação acompanha aproximadamente a frequência com que você encontrará cada um no mundo real.

A01:2025 - Broken Access Control

Broken access control é quando uma aplicação falha em impor o que um usuário tem permissão de fazer, permitindo que ele leia ou altere dados que deveriam estar fora de alcance. É o risco web número um desde 2021 e permaneceu lá em 2025, agora absorvendo o Server-Side Request Forgery como um subcaso.

O exemplo clássico é uma Insecure Direct Object Reference. Você visualiza sua própria fatura em /invoice?id=1043, muda o número para 1044, e a aplicação entrega a fatura de outra pessoa porque verificou que você estava logado mas nunca verificou que o registro pertencia a você. A mesma falha abrange forced browsing para páginas de administração, adulteração de uma claim de função em um JWT e alcançar serviços internos por meio de uma requisição que o servidor faz em seu nome (o caso de SSRF agora incorporado aqui).

Pratique no laboratório IDOR Explorer, escale para um painel de administração no Admin Portal Breach, ou explore a variante de server-side request forgery no SSRF Validator.

A02:2025 - Security Misconfiguration

Security misconfiguration é um sistema deixado em um estado inseguro por padrões, descuidos ou recursos desnecessários em vez de um bug de código. Subiu do quinto lugar em 2021 para o segundo em 2025, o que reflete o quanto as violações modernas vêm de configuração desleixada em vez de exploração engenhosa.

Pense em credenciais padrão deixadas em um console de administração, um bucket de armazenamento em nuvem definido como público, listagem de diretórios habilitada, páginas de erro verbosas que vazam stack traces, ou uma pasta .git exposta que entrega ao atacante toda a sua árvore de código-fonte. Nada disso exige um zero-day. Exige que alguém perceba que a porta nunca foi trancada.

O laboratório Git Exposed permite que você reconstrua uma aplicação a partir de um repositório implantado sem cuidado, e o curso Web Security Basics cobre os erros de configuração que causam essa classe.

A03:2025 - Software Supply Chain Failures

Software supply chain failures abrangem riscos introduzidos pelos componentes, dependências e pipelines de build dos quais sua aplicação depende, em vez de código que sua equipe escreveu. Em 2025 o OWASP ampliou a antiga categoria "Vulnerable and Outdated Components" para toda a cadeia de suprimentos, porque a forma como o software é construído mudou mais rápido do que o nome antigo permitia.

Uma dependência com um CVE conhecido que você nunca corrigiu é o caso mais simples. O Log4Shell foi uma falha em uma biblioteca que expôs milhões de aplicações da noite para o dia. Piores são os comprometimentos ativos: a conta de um mantenedor sofre phishing e uma versão maliciosa de um pacote npm popular é enviada a todos que rodam uma atualização. Seu código pode estar perfeito e ainda assim você é comprometido por um pacote que nunca leu.

Defender-se dessa classe significa conhecer suas dependências, fixar versões, verificar assinaturas e escanear seu build. O curso Container and Kubernetes Security cobre a integridade da cadeia de suprimentos para builds em contêiner, onde esse risco se concentra.

A04:2025 - Cryptographic Failures

Cryptographic failures acontecem quando dados sensíveis não são protegidos adequadamente, seja por algoritmos fracos, ausência de criptografia ou má gestão de chaves. Ficava em segundo lugar em 2021 e passou para quarto em 2025, não porque se tornou menos grave mas porque misconfiguration e supply chain subiram acima dele.

O exemplo do dia a dia é o armazenamento de senhas. Uma aplicação que armazena senhas como hashes MD5 sem salt praticamente as armazenou em texto puro, porque um hash MD5 vazado de uma senha comum é quebrado em milissegundos. Outros casos incluem transmitir dados por HTTP simples, embutir uma chave de criptografia no código-fonte, ou usar um modo de cifra quebrado que vaza padrões no texto cifrado.

Para sentir por que o hashing fraco falha, quebre hashes reais no laboratório Crack SHA1 Hash, depois leia nosso tutorial de quebra de hash e nossa explicação sobre por que não dá para simplesmente reverter um hash MD5. O curso Password Cracking mostra o lado ofensivo de ponta a ponta.

A05:2025 - Injection

Injection é quando uma entrada não confiável é interpretada como um comando ou consulta, permitindo que um atacante mude o que a aplicação faz. Inclui SQL injection, cross-site scripting, command injection, LDAP injection e NoSQL injection, todos compartilhando uma causa raiz: dados cruzando para um lugar destinado a código. Injection caiu do terceiro lugar em 2021 para o quinto em 2025, à medida que os frameworks tornaram os casos comuns mais difíceis, mas ele não desapareceu.

O caso didático é o SQL injection. Um formulário de login constrói uma consulta colando sua entrada diretamente em uma string, então digitar ' OR '1'='1 como senha transforma a consulta em uma que é sempre verdadeira e loga você como o primeiro usuário na tabela. Cross-site scripting é a mesma ideia direcionada ao navegador: um campo de comentário que ecoa <script> de volta sem escape roda seu JavaScript na sessão de cada visitante.

Explore SQL injection na prática no Query Quake, um dos laboratórios mais populares da HackerDNA, e cross-site scripting no XSS Playground. Nosso tutorial de SQL injection e nossa análise de XSS vs CSRF aprofundam nos dois que você mais encontrará.

A06:2025 - Insecure Design

Insecure design é uma falha na lógica pretendida de uma aplicação em vez de um erro em sua implementação. Você não consegue corrigi-la com um cabeçalho de segurança porque o problema é o próprio plano. Ficava em quarto lugar em 2021 e está em sexto em 2025, ainda um lembrete de que nem todo bug é um erro de digitação.

Um fluxo de redefinição de senha que envia um código de seis dígitos mas nunca limita quantas tentativas você tem é projetado de forma insegura: o código está bem, a ausência de rate limiting é o buraco. Falhas de lógica de negócio também moram aqui, como um checkout que permite aplicar o mesmo desconto de uso único mil vezes, ou uma transferência que aceita um valor negativo e move o dinheiro na direção errada.

Essas precisam de um testador que pense em como o recurso pode ser abusado, não apenas se ele funciona. O laboratório API Logic Flaw é construído exatamente em torno desse tipo de fraqueza no nível do design.

A07:2025 - Authentication Failures

Authentication failures são fraquezas em como uma aplicação confirma quem é um usuário e o mantém logado. O OWASP encurtou o nome de 2021 "Identification and Authentication Failures" para apenas "Authentication Failures" em 2025, mas a essência é a mesma. Permaneceu em sétimo.

As falhas se agrupam em alguns lugares: permitir senhas fracas ou vazadas, não se defender contra credential stuffing, expor tokens de sessão que nunca expiram e lidar mal com JSON Web Tokens. Uma biblioteca de JWT que aceita o cabeçalho alg: none confiará em um token que um atacante forjou sem assinatura nenhuma, entregando qualquer conta que ele indicar.

Quebre um login no Hack the Login, percorra um bypass de autenticação no Auth Bypass e forje tokens no JWT Algorithm Confusion. O curso JWT Hacking cobre ataques a tokens em profundidade.

A08:2025 - Software or Data Integrity Failures

Software or data integrity failures ocorrem quando uma aplicação confia em código ou dados sem verificar que não foram adulterados. O nome de 2025 troca "and" por "or" mas mantém o significado de 2021. Permaneceu em oitavo.

Insecure deserialization é o exemplo mais afiado. Uma aplicação que faz unpickle de um objeto Python ou unserialize de um objeto PHP a partir de entrada do usuário pode ser enganada a executar código escolhido pelo atacante, transformando um campo de dados em execução remota de código. A categoria também cobre mecanismos de atualização automática que buscam código por um canal não verificado e pipelines de CI/CD que implantam artefatos sem verificar uma assinatura.

Coloque a mão na massa com o laboratório Pickle Deserializer, onde um objeto serializado confiável vira um shell, e o laboratório Type Juggling Bypass para uma falha de integridade relacionada em comparações frouxas.

A09:2025 - Security Logging and Alerting Failures

Security logging and alerting failures significam que uma aplicação não registra eventos relevantes para a segurança ou não dispara um alarme quando algo dá errado, então os ataques passam despercebidos. O OWASP renomeou o "Monitoring" de 2021 para "Alerting" em 2025 para ressaltar que coletar logs é inútil se ninguém os está observando. Permaneceu em nono.

O dano aqui é medido em tempo. Um site que nunca registra logins falhos não consegue perceber que alguém rodou um ataque de credential stuffing por três semanas. O dwell time médio do setor, a distância entre uma violação e sua detecção, ainda é medido em semanas ou meses, e a ausência de logs é grande parte do porquê. Esta é a única categoria da lista que te prejudica como defensor mais do que te ajuda como atacante, e é por isso que existem os blue teams.

O lado do defensor disso é onde vive a análise de logs. Pratique extrair ataques de logs no laboratório Log Hunter e veja o fluxo completo de detecção no curso Digital Forensics and Incident Response.

A10:2025 - Mishandling of Exceptional Conditions

Mishandling of exceptional conditions é uma categoria totalmente nova de 2025 que cobre o que acontece quando uma aplicação encontra um erro ou um estado inesperado e o trata de forma insegura. Ela substitui o SSRF no décimo lugar, já que o SSRF subiu para o Broken Access Control.

O padrão perigoso é a lógica fail-open. Imagine uma verificação de autorização que lança uma exceção quando um serviço está inacessível, e o código ao redor trata a exceção como "permitir" em vez de "negar". O sistema falha a favor do atacante. Essa classe também cobre respostas de erro verbosas que vazam um stack trace com credenciais de banco de dados, e exceções não tratadas que deixam a aplicação em um estado meio processado e explorável.

O laboratório Flask Error mostra como uma exceção mal tratada derrama detalhes sensíveis que um atacante pode usar, que é a face cotidiana dessa nova categoria.

O que mudou no OWASP Top 10 2025 vs 2021

Se você aprendeu a lista pela edição de 2021, a maior parte dela ainda vale. Broken Access Control continua em primeiro, e o meio da lista se mexeu sem cair muito. Três mudanças valem conhecer.

Primeiro, duas categorias são efetivamente novas. Software Supply Chain Failures cresceu a partir da mais estreita "Vulnerable and Outdated Components" de 2021 e agora cobre toda a cadeia de build e dependências. Mishandling of Exceptional Conditions é genuinamente nova, adicionada porque falhas de tratamento de erros apareciam em várias violações sem um lugar na lista.

Segundo, o SSRF sumiu como entrada independente. Em 2021 ele conquistou seu próprio décimo lugar com base na pesquisa; em 2025 os dados o colocaram dentro do Broken Access Control, onde ele se encaixa como uma requisição que o servidor não deveria ter tido permissão de fazer. Ele não se tornou menos importante, foi reclassificado.

Terceiro, a classificação foi reembaralhada. Security Misconfiguration subiu do quinto para o segundo, Cryptographic Failures escorregou do segundo para o quarto, e Injection recuou do terceiro para o quinto. Aqui está o lado a lado.

Como usar o OWASP Top 10

A lista é um ponto de partida, não uma linha de chegada. O próprio OWASP diz que o Top 10 é um documento de conscientização, e tratá-lo como todo o seu programa de segurança é a forma mais comum de as pessoas usarem-no errado. Como você o aplica depende de qual lado da aplicação você está.

Se você desenvolve software

Use o Top 10 como uma lente de design e revisão, não uma lista de bugs para limpar no final. Antes de um recurso entrar em produção, faça as perguntas que a lista sugere: isso impõe controle de acesso em cada objeto, trata toda entrada como hostil, registra eventos de segurança, falha de forma fechada quando algo quebra. Incorpore isso na revisão de código e você pega categorias inteiras antes que existam. Comece pelos fundamentos no curso Web Security Basics, que cobre como esses riscos se mapeiam ao código que você escreve.

Se você testa software

Use o Top 10 como um mapa de cobertura para que um teste não persiga um único bug chamativo e perca uma classe inteira. Profissionais o combinam com o mais profundo OWASP Web Security Testing Guide, que transforma cada risco em casos de teste específicos com identificadores que você pode rastrear. Para o fluxo completo de engajamento em torno desses testes, nosso guia de teste de intrusão em aplicações web mostra como as peças se encaixam em uma avaliação real.

A ressalva honesta, que vale dizer com clareza: o Top 10 não é exaustivo e nunca foi feito para ser. São os dez riscos que mais aparecem, o que significa que um atacante determinado usará com prazer o décimo primeiro. Aprenda a lista para construir uma base, depois continue além dela. O valor é que ela dá a todos, desenvolvedores, testadores e triadores, um vocabulário compartilhado para os riscos que mais importam.

Como testar o OWASP Top 10

Você não aprende esses riscos lendo sobre eles, e não pode praticá-los legalmente em aplicações que não são suas. Você precisa de alvos feitos para isso. O conjunto de ferramentas para encontrar falhas do Top 10 é pequeno e vale conhecer bem.

• Burp Suite é o proxy de interceptação no centro dos testes web. Você o usará para adulterar controle de acesso, repetir payloads de injection e inspecionar tokens. A Community Edition gratuita cobre tudo o que um iniciante precisa.
• sqlmap automatiza a extração de SQL injection depois que você confirmou um ponto de injeção manualmente. Confirme na mão primeiro, depois deixe-o fazer a parte tediosa.
• Um navegador e suas ferramentas de desenvolvedor bastam para encontrar um número surpreendente de falhas de controle de acesso e de misconfiguration. Mude um ID, leia um erro verboso, note um token que nunca expira.
• Nuclei e scanners de dependências pegam rápido as classes de misconfiguration e de componentes vulneráveis, que é onde a automação genuinamente merece seu lugar.

Na prática, a maioria dos achados reais vem de um humano notando algo que um scanner não consegue julgar. Uma ferramenta sinaliza que uma referência a objeto existe; só uma pessoa sabe que aquele objeto deveria ter pertencido a outra pessoa. Essa lacuna é o trabalho inteiro. A forma mais rápida de construir o instinto é explorar cada risco por conta própria algumas vezes em um laboratório controlado até que o padrão seja óbvio.

Considerações legais e éticas

As técnicas neste guia são as mesmas que os criminosos usam, e a única coisa que separa um pentester de um réu é a permissão. Testar suas próprias aplicações é legal. Testar o site de uma empresa porque você viu uma pasta .git aberta não é, por mais óbvia que seja a falha ou boas que sejam suas intenções.

Há três lugares para praticar legalmente. Programas de bug bounty em plataformas como HackerOne e Bugcrowd concedem permissão para testar dentro de regras publicadas. Engajamentos pagos rodam sob um documento de escopo assinado. Plataformas de laboratório em sandbox e eventos de CTF dão a você alvos que a plataforma possui e oferece de propósito. Tudo neste guia é destinado a esses três lugares e a nenhum outro.