OWASP Top 10 explicado com exemplos (2026)

O que é o OWASP Top 10

A OWASP (Open Worldwide Application Security Project) é uma fundação sem fins lucrativos que publica materiais abertos de segurança de software. O Top 10 é o documento mais conhecido dela: um ranking das dez categorias de risco mais críticas em aplicações web, atualizado a cada poucos anos a partir de dados reais coletados de centenas de milhares de aplicações.

Cada item não é uma vulnerabilidade única, e sim uma categoria que agrupa dezenas de falhas parecidas. "Injeção", por exemplo, abrange SQL injection, injeção de comandos de SO, injeção de LDAP e mais. Por isso o Top 10 serve como vocabulário comum entre devs, times de segurança e auditores — e como checklist mínimo de cobertura, não como lista completa de tudo que pode dar errado.

As 10 categorias, uma a uma

A01 — Broken Access Control

Controle de acesso quebrado. A aplicação não valida direito o que cada usuário pode ver ou fazer, então alguém acessa dados ou ações de outra pessoa. É o risco nº 1 de novo em 2025. Exemplo: trocar /api/pedidos/1043 por /api/pedidos/1044 na URL e ver o pedido de outro cliente (IDOR). Como se testa/previne: negar por padrão e testar cada endpoint autenticado com o token de outro usuário — se o dado de terceiros aparecer, está quebrado.

A02 — Security Misconfiguration

Configuração incorreta de segurança. O código está certo, mas a configuração deixou uma porta aberta: default de fábrica, permissão frouxa, serviço exposto. Exemplo: um painel de admin ou um bucket de storage acessível sem autenticação, ou uma mensagem de erro que devolve o stack trace inteiro com caminhos e versões. Como se testa/previne: endurecer o ambiente (headers de segurança, remover contas/páginas default) e escanear a superfície exposta a cada deploy.

A03 — Software Supply Chain Failures

Falhas na cadeia de suprimentos de software. Categoria nova em 2025: o risco vem de terceiros que você importa — bibliotecas, imagens de container, ações de CI, plugins. Exemplo: um pacote npm popular é comprometido e passa a exfiltrar variáveis de ambiente; seu build o instala sem você perceber. Como se testa/previne: fixar versões, gerar um SBOM, verificar integridade de dependências e monitorar avisos de pacotes comprometidos, não só CVEs conhecidas.

A04 — Cryptographic Failures

Falhas criptográficas. Dado sensível trafega ou é armazenado sem proteção adequada — sem cifra, com algoritmo fraco ou com chave exposta. Exemplo: senhas guardadas em MD5 (ou em texto puro), ou uma API que aceita tráfego em HTTP sem TLS. Como se testa/previne: cifrar dados sensíveis em trânsito e em repouso, usar hashing forte para senhas (bcrypt/argon2) e nunca deixar chave/segredo hardcoded no repositório.

A05 — Injection

Injeção. Entrada do usuário é interpretada como código ou comando pelo backend, em vez de tratada como dado. Cobre SQL injection, injeção de comandos de SO, XSS e outras. Exemplo: um campo de busca que monta SELECT ... WHERE nome = '$input' e um atacante envia ' OR '1'='1 para vazar a tabela inteira. Como se testa/previne: usar queries parametrizadas e validação de entrada — veja o que é SQL injection e como se proteger.

A06 — Insecure Design

Design inseguro. A falha está na arquitetura, não em um bug pontual: faltou pensar no abuso na hora de projetar o fluxo. Nenhum patch conserta — precisa redesenhar. Exemplo: um fluxo de "esqueci minha senha" que usa uma pergunta secreta trivial ("nome do seu pet") como única barreira, ou um checkout sem limite de tentativas. Como se testa/previne: threat modeling na fase de design e testes de abuso dos fluxos de negócio, não só dos endpoints técnicos.

A07 — Authentication Failures

Falhas de autenticação e identificação. Mecanismos que confirmam quem é o usuário falham, permitindo que alguém se passe por outro. Exemplo: login sem limite de tentativas (abrindo brute force), sessões que nunca expiram, ou um token JWT aceito mesmo com assinatura inválida. Como se testa/previne: exigir MFA onde importa, aplicar rate limiting no login, invalidar sessões corretamente e validar sempre a assinatura dos tokens.

A08 — Software or Data Integrity Failures

Falhas de integridade de software ou dados. A aplicação confia em código, atualizações ou dados sem verificar se foram adulterados no caminho. Exemplo: um pipeline de CI/CD que puxa e roda um script de uma fonte externa sem checar assinatura, ou desserialização de um objeto vindo do cliente sem validação. Como se testa/previne: assinar e verificar artefatos e atualizações, e nunca desserializar dado não confiável sem checagem de integridade.

A09 — Security Logging and Alerting Failures

Falhas de registro e alerta de segurança. Sem logs e alertas adequados, um ataque acontece e ninguém percebe — nem durante, nem depois. Exemplo: milhares de tentativas de login falhas não geram nenhum alerta, e o incidente só é descoberto meses depois pelo próprio atacante vazando os dados. Como se testa/previne: registrar eventos de segurança (logins, falhas, acessos negados), monitorar em tempo real e testar se um evento suspeito realmente dispara alerta.

A10 — Mishandling of Exceptional Conditions

Tratamento inadequado de condições excepcionais. Categoria nova em 2025: erros, exceções e casos de borda mal tratados que expõem informação ou levam o sistema a um estado inseguro (fail-open). Exemplo: quando o serviço de autorização cai, a aplicação libera o acesso em vez de negar; ou uma exceção não tratada devolve dados internos na resposta. Como se testa/previne: falhar de forma segura (fail-closed) por padrão, tratar exceções sem vazar detalhes e testar o comportamento sob erro, não só o caminho feliz.

Tabela-resumo (OWASP Top 10:2025)

Como o Escudo Code testa essas categorias

A maioria das ferramentas só cruza versões e devolve uma lista de CVEs teóricas — não prova nada. O Escudo Code é diferente: ele explora de verdade cada categoria do Top 10. Tenta o IDOR de A01 trocando o ID e confirmando o dado de terceiros; dispara o payload de injeção de A05 e verifica a resposta; forja o JWT de A07 para ver se passa. Só reporta o que confirmou explorando, com evidência e severidade CVSS.

Isso já rendeu mais de 900 vulnerabilidades confirmadas — 508 delas críticas ou altas — validado em alvos como o OWASP Juice Shop e o VAmPI. APIs REST concentram boa parte de A01, A05 e A07 na prática; veja as vulnerabilidades mais comuns em APIs REST. Para ver como testamos ou os planos, confira como funciona o Escudo Code e os preços.