O que é o OWASP Top 10, o que cada categoria de 2025 significa, como se defender e como mapear desafios do Juice Shop.
O OWASP Top 10 é uma lista curta com as dez categorias de risco mais importantes para aplicações web. OWASP é o Open Worldwide Application Security Project, uma organização sem fins lucrativos que publica orientações de segurança gratuitas. A edição atual é a de 2025, a oitava da lista.
O Top 10 é um documento de conscientização. A função dele é dar nome às falhas que aparecem de novo e de novo em aplicações reais, para que desenvolvedores, testers e gestores falem sobre elas com as mesmas palavras. Ele não é um teste, uma certificação nem uma lista de verificação pronta. O resto deste artigo mostra por quê.
A edição de 2025 combina dois tipos de evidência. O primeiro são dados de testes: treze organizações nomeadas, além de vários doadores anônimos, enviaram resultados que cobrem mais de 2,8 milhões de aplicações. Cada colaborador contou quantas das suas aplicações tinham pelo menos uma ocorrência de determinada fraqueza. O segundo são dados de vulnerabilidades: cerca de 220 mil registros CVE da National Vulnerability Database dos Estados Unidos, mapeados para 643 CWEs. Testes automatizados não enxergam tudo, por isso duas das dez categorias foram escolhidas por uma pesquisa com a comunidade.
Cada categoria agrupa CWEs relacionadas. CWE é a Common Weakness Enumeration, um catálogo de tipos de fraqueza mantido pela MITRE. A OWASP diz que a lista de 2025 agrupa 248 CWEs nas suas dez categorias.
A maior parte das falhas de segurança web vem de um pequeno conjunto de decisões repetidas. Uma aplicação confia num valor que o navegador enviou. Uma rota verifica que o usuário está logado, mas nunca verifica se ele é dono do registro. Uma senha é guardada de um jeito que deixa de valer nada quando o banco vaza. Uma biblioteca chega de uma fonte que ninguém verificou. O Top 10 dá nome a essas decisões.
Os nomes ajudam em três momentos. Numa revisão de design, você pergunta onde o controle de acesso é decidido. Numa revisão de código, você aponta uma checagem de dono que falta e cita a A01. Num relatório de incidente, descreve a causa raiz em vez do sintoma. Quem conhece as categorias também tem um mapa para ler qualquer conselho de segurança, venha de onde vier.
A ordem abaixo segue a edição de 2025. Ela serve para leitura, não é um ranking do que corrigir primeiro na sua aplicação. Cada seção traz uma explicação curta, um exemplo simples, a defesa principal, as CWEs que a OWASP associa à categoria e uma cheat sheet.
O controle de acesso decide o que um usuário autenticado pode fazer. Esta categoria cobre os casos em que essa decisão está ausente, errada ou aplicada só no navegador. A OWASP informa que todas as aplicações testadas tinham alguma forma dessa falha.
Exemplo: a página de um pedido carrega em /orders/1041. Trocar o número para /orders/1042 mostra o pedido de outro cliente, porque o servidor nunca confere quem é o dono do pedido.
Defesa principal: negar por padrão e verificar propriedade e permissões no servidor, em toda requisição. Coloque a checagem em código compartilhado do servidor, não em cada handler.
CWEs: CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization, CWE-918 Server-Side Request Forgery (SSRF), entre 40 entradas mapeadas.
Cheat sheet: Authorization Cheat Sheet.
Um sistema é tão seguro quanto a configuração com que roda. Esta categoria cobre contas padrão mantidas, recursos de depuração ligados, mensagens de erro detalhadas demais, cabeçalhos de segurança ausentes e armazenamento em nuvem com permissões erradas.
Exemplo: um servidor de homologação roda com a senha padrão de administrador do guia de instalação e mostra o stack trace completo para qualquer visitante.
Defesa principal: use um processo de hardening repetível. Mantenha desenvolvimento, QA e produção configurados do mesmo jeito, com credenciais diferentes em cada um, e remova os recursos, exemplos e frameworks que você não usa.
CWEs: CWE-16 Configuration, CWE-260 Password in Configuration File, CWE-15 External Control of System or Configuration Setting, entre 16 entradas mapeadas.
Referência: capítulo V13 Configuration do ASVS. A OWASP não lista cheat sheet para esta categoria.
Sua aplicação executa código que você não escreveu. Esta categoria cobre o caminho que o software percorre da origem até a produção: dependências, ferramentas de build, registries e canais de atualização. A OWASP observa que a categoria cresceu além dos componentes com vulnerabilidades conhecidas e que ela ficou em primeiro lugar na pesquisa com a comunidade.
Exemplo: um pequeno pacote utilitário da sua árvore de dependências é trocado por uma versão com código malicioso, e o seu próximo build instala essa versão sem que ninguém leia a mudança.
Defesa principal: saiba o que você entrega. Gere um SBOM (software bill of materials), acompanhe as dependências transitivas, remova pacotes que não usa e mantenha o inventário de versões atualizado de forma contínua, e não só uma vez por ano.
CWEs: CWE-1104 Use of Unmaintained Third Party Components, CWE-1395 Dependency on Vulnerable Third-Party Component, e outras quatro entradas mapeadas.
Cheat sheets: Vulnerable Dependency Management Cheat Sheet e Dependency Graph SBOM Cheat Sheet.
Esta categoria cobre a ausência de criptografia, algoritmos fracos ou desatualizados, gestão ruim de chaves e verificações de certificado que são puladas. O erro comum muitas vezes não é um algoritmo quebrado, e sim uma decisão que ficou de fora: o dado trafega em HTTP puro, ou fica guardado num lugar que ninguém revisou.
Exemplo: um formulário de login envia senhas em HTTP puro, ou guarda as senhas com um hash rápido e sem salt.
Defesa principal: primeiro classifique os seus dados e depois decida o que precisa de criptografia em trânsito e em repouso. Use implementações confiáveis de algoritmos padronizados, proteja as chaves mais sensíveis num HSM e não guarde dado sensível que você não precisa.
CWEs: CWE-261 Weak Encoding for Password, CWE-319 Cleartext Transmission of Sensitive Information, CWE-321 Use of Hard-coded Cryptographic Key, entre 32 entradas mapeadas.
Cheat sheets: Transport Layer Protection Cheat Sheet, Password Storage Cheat Sheet e Cryptographic Storage Cheat Sheet.
Injection acontece quando uma entrada não confiável chega a um interpretador, como um motor de consultas SQL, o shell do sistema operacional ou o navegador, e o interpretador executa parte dessa entrada como instrução. A OWASP lista como formas comuns a injeção de SQL, de NoSQL, de comandos do sistema operacional, de ORM, de LDAP e de expression language. Na edição de 2025, o cross-site scripting (XSS) também entra nesta categoria.
Exemplo: um handler de busca monta a consulta colando o texto do usuário dentro da string SQL. Um caractere de aspas no texto muda o significado da consulta.
Defesa principal: use uma API segura que mantenha os dados separados dos comandos, como consultas parametrizadas ou um ORM. Valide a entrada no servidor com listas de permissão. Quando uma saída dinâmica for inevitável, use as regras de escape do interpretador de destino, e lembre que identificadores como nomes de tabela não podem ser escapados desse jeito.
CWEs: CWE-20 Improper Input Validation, CWE-74 Injection, CWE-78 OS Command Injection, CWE-79 Cross-site Scripting, entre 37 entradas mapeadas.
Cheat sheets: Injection Prevention Cheat Sheet e SQL Injection Prevention Cheat Sheet.
Nenhuma implementação consegue consertar um design que nunca previu uma defesa. Esta categoria cobre controles que nunca foram planejados: lógica de negócio que pode ser abusada, fluxos de recuperação que dependem de respostas adivinháveis ou privilégios concedidos por padrão em vez de por política.
Exemplo: um endpoint de desconto aceita o mesmo cupom várias vezes, porque ninguém modelou o reuso como ameaça.
Defesa principal: faça threat modeling dos fluxos críticos, como autenticação, controle de acesso e pagamentos, antes de escrever o código. O artigo sobre threat modeling mostra uma forma de fazer essas perguntas. Reaproveite padrões e componentes de design seguro já revisados em vez de inventar um novo para cada funcionalidade.
CWEs: CWE-269 Improper Privilege Management, CWE-256 Unprotected Storage of Credentials, CWE-73 External Control of File Name or Path, entre 39 entradas mapeadas.
Cheat sheet: Secure Product Design Cheat Sheet.
Essas falhas deixam entrar a pessoa errada, ou deixam um atacante tentar até uma tentativa funcionar. Entram aqui o credential stuffing, a password spraying, a recuperação de conta fraca, a falta de autenticação multifator (MFA) e sessões que continuam válidas depois do logout.
Exemplo: um login de administrador não tem limite de tentativas nem MFA. O atacante testa pares de usuário e senha vindos de vazamentos anteriores até um deles funcionar.
Defesa principal: ative MFA onde for possível, bloqueie tentativas automatizadas, remova contas padrão e verifique as senhas novas contra uma lista de senhas comuns. A OWASP sugere checar contra as 10.000 piores senhas.
CWEs: CWE-287 Improper Authentication, CWE-259 Use of Hard-coded Password, CWE-290 Authentication Bypass by Spoofing, entre 36 entradas mapeadas.
Cheat sheet: Authentication Cheat Sheet.
Integridade significa saber que o código ou o dado veio de onde você esperava e não foi alterado no caminho. Esta categoria cobre atualizações automáticas sem verificação de assinatura, scripts carregados de um CDN sem checagem de integridade, pipelines de CI/CD que puxam artefatos de lugares não verificados e a desserialização de objetos não confiáveis.
Exemplo: uma página carrega um arquivo JavaScript de um CDN de terceiros sem o atributo de integridade. Se esse CDN servir um arquivo alterado, todos os visitantes executam o código alterado.
Defesa principal: assine o que você entrega e verifique a assinatura antes de usar. Limite os gerenciadores de pacotes a repositórios confiáveis, exija revisão para mudanças de pipeline e de configuração e proteja o próprio sistema de CI/CD.
CWEs: CWE-345 Insufficient Verification of Data Authenticity, CWE-494 Download of Code Without Integrity Check, CWE-502 Deserialization of Untrusted Data, entre 14 entradas mapeadas.
Cheat sheet: Software Supply Chain Security Cheat Sheet.
Sem logs e alertas, uma invasão pode passar meses sem ser percebida. Esta categoria cobre registros ausentes de logins e de falhas de controle de acesso, logs guardados só na máquina que pode ser comprometida, alertas que ninguém lê e logs que vazam segredos ou podem ser forjados.
Exemplo: as falhas de login numa conta de administrador nunca são registradas, e a linha de log de uma redefinição de senha contém a senha nova.
Defesa principal: registre falhas de autenticação e de controle de acesso com contexto suficiente para investigar, codifique os dados do log antes de gravar, mantenha segredos fora do log e envie os logs para um lugar que o host da aplicação não consiga reescrever.
CWEs: CWE-778 Insufficient Logging, CWE-532 Insertion of Sensitive Information into Log File, CWE-117 Improper Output Neutralization for Logs, entre 5 entradas mapeadas.
Cheat sheets: Logging Cheat Sheet e Application Logging Vocabulary Cheat Sheet.
Software falha, e esta categoria trata de como ele falha. Um sistema pode cair num estado que vaza dados, pular uma checagem quando uma chamada devolve erro ou continuar uma operação de vários passos depois que um deles falhou.
Exemplo: uma chamada de pagamento expira, o código trata o timeout como sucesso e o pedido sai para entrega sem ter sido pago.
Defesa principal: capture os erros onde eles acontecem e trate cada um de propósito. Adicione um handler global de exceções como rede de segurança. Quando uma operação de vários passos falhar no meio, faça rollback e falhe de forma fechada.
CWEs: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-252 Unchecked Return Value, CWE-248 Uncaught Exception, entre 24 entradas mapeadas.
Cheat sheet: Error Handling Cheat Sheet.
Três limites mantêm a lista no seu lugar.
Ele não é um padrão completo. Dez categorias não conseguem descrever todos os requisitos de uma aplicação segura, e muitos riscos ficam fora da lista. Passar numa revisão feita com base no Top 10 não torna uma aplicação segura.
Ele não é uma lista de verificação que dá para terminar. As categorias descrevem causas, então uma mesma funcionalidade pode tocar várias delas, e uma categoria cobre bugs bem diferentes entre si. Quem trata a lista como checklist costuma corrigir os exemplos e manter o padrão que os gerou.
Ele não é o lugar onde os requisitos são definidos. Para isso a OWASP publica o Application Security Verification Standard (ASVS). O ASVS é um conjunto de requisitos de segurança para projetar, construir e testar aplicações e serviços web. A versão atual é a 5.0.0, publicada em 30 de maio de 2025. Use o Top 10 para explicar o risco e decidir onde olhar primeiro. Use o ASVS quando precisar de requisitos para construir e verificar.
Lembre também que um mesmo bug pode casar com mais de uma categoria. A CWE-209 fica na A10, mas uma página de erro detalhada costuma ser também um problema da A02. Escolha a entrada que melhor nomeia a causa raiz e explique o motivo.
Neste laboratório você roda o OWASP Juice Shop, uma aplicação web intencionalmente vulnerável, na sua própria máquina. Você lê o scoreboard dele e mapeia três categorias de desafio para entradas do Top 10. Você não explora nada. Leia as descrições dos desafios, não as soluções.
O Juice Shop serve para aprender. Mantenha-o preso ao localhost e nunca o exponha a uma rede que você não controla.
Você precisa do Docker. A saída abaixo veio do Docker 29.8.2 no Windows 11 com Git Bash. Os comandos funcionam em qualquer shell POSIX.
docker --version
docker info --format '{{.ServerVersion}}'Saída observada:
Docker version 29.8.2, build 7fc2dff
29.8.2docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shopO prefixo 127.0.0.1: publica a porta só na interface de loopback, então outras máquinas da sua rede não conseguem acessá-la. Na máquina onde rodei estes passos, já havia um contêiner dessa mesma imagem em execução com o nome juice-local, então não subi um segundo. Confira o que está rodando:
docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'A linha do Juice Shop na saída observada:
juice-local bkimminich/juice-shop 127.0.0.1:3000->3000/tcpcurl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
curl -s http://127.0.0.1:3000/rest/admin/application-versionSaída observada:
200
{"version":"20.3.0"}A sua versão pode ser diferente. Anote-a, porque os nomes e as categorias dos desafios mudam entre versões.
Salve a lista de desafios e conte as categorias:
curl -s http://127.0.0.1:3000/api/Challenges/ -o challenges.json
python -c "import json,collections; d=json.load(open('challenges.json'))['data']; print(len(d)); [print(v,k) for k,v in sorted(collections.Counter(x['category'] for x in d).items())]"Saída observada:
116
12 Broken Access Control
4 Broken Anti Automation
9 Broken Authentication
5 Cryptographic Issues
12 Improper Input Validation
14 Injection
3 Insecure Deserialization
6 Miscellaneous
4 Observability Failures
5 Security Misconfiguration
3 Security through Obscurity
17 Sensitive Data Exposure
2 Unvalidated Redirects
9 Vulnerable Components
9 XSS
2 XXEAbra http://127.0.0.1:3000/#/score-board no navegador. Compare as categorias que você vê com as contagens acima. Se os números forem diferentes, anote a versão do Juice Shop, já que o conjunto de desafios muda entre versões.
Use a tabela abaixo. É um mapeamento razoável entre vários possíveis. O seu pode ser diferente, desde que você consiga justificá-lo em uma frase.
| Categoria no Juice Shop | Desafios na categoria | Desafio de exemplo (dificuldade de 1 a 6) | Descrição no scoreboard | Entrada do Top 10:2025 |
|---|---|---|---|---|
| Broken Access Control | 12 | Admin Section (2) | Access the administration section of the store. | A01 Broken Access Control |
| Injection | 14 | Login Admin (2) | Log in with the administrator's user account. | A05 Injection |
| Security Misconfiguration | 5 | Error Handling (1) | Provoke an error that is neither very gracefully nor consistently handled. | A02 Security Misconfiguration |
Por que cada linha se encaixa:
Os nomes de categoria do Juice Shop são rótulos próprios dele, não da OWASP. A categoria XSS, por exemplo, cai na A05 da lista de 2025. Mapeie pela causa raiz e cite a CWE na sua anotação.
Liste os contêineres e depois pare aquele que você subiu:
docker ps --format '{{.Names}} {{.Image}}'
docker stop <container-name>
docker rm <container-name>Troque <container-name> pelo nome que aparecer no primeiro comando. Como o contêiner foi iniciado com -d e sem --rm, depois de parado ele continua no disco até você removê-lo.
0.0.0.0 ou num host de nuvem coloca uma aplicação intencionalmente vulnerável na internet.Segurança web e de APIs
Como a SQL Injection muda o sentido de uma consulta, por que consultas parametrizadas resolvem o problema e um laboratório com Juice Shop e sqlite3.
Segurança web e de APIs
Entenda XSS refletido, armazenado e baseado em DOM, por que a codificação depende do contexto e como a CSP reduz o risco, em laboratório local.
Segurança web e de APIs
CSRF usa os cookies do seu próprio navegador contra você. Veja as defesas da mais forte para a mais fraca e teste o SameSite com um laboratório Flask.