Toda aplicação web que sua empresa publica é, ao mesmo tempo, um ativo de negócio e uma porta de entrada. O OWASP Top 10 é o mapa mais usado do mundo para fechar essas portas: uma lista priorizada dos dez riscos de segurança de aplicações mais críticos, mantida por uma comunidade global e adotada como referência de fato por times de desenvolvimento, auditorias e reguladores. Entender cada um desses riscos, e o que fazer a respeito, é o ponto de partida de qualquer programa sério de segurança de aplicações (AppSec).
O que é o OWASP Top 10 e por que ele virou referência
A OWASP (Open Worldwide Application Security Project) é uma fundação sem fins lucrativos dedicada a melhorar a segurança de software. Seu projeto mais conhecido, o Top 10, é um documento de conscientização que consolida os dez riscos mais sérios para aplicações web. A força do documento vem da metodologia: a OWASP combina dados de teste coletados de centenas de organizações, cobrindo centenas de milhares de aplicações, com uma pesquisa de comunidade que captura riscos emergentes ainda pouco representados nos dados. O resultado é uma lista que reflete tanto o que já está acontecendo quanto o que está prestes a acontecer.
Essa combinação de rigor e abertura fez o Top 10 ser incorporado por padrões e contratos no mundo todo. O PCI DSS, normas setoriais e cláusulas de contratos de desenvolvimento frequentemente exigem, de forma explícita, que a aplicação seja livre dos riscos do OWASP Top 10. Para um time de produto, dominar a lista deixou de ser diferencial e passou a ser requisito básico de entrada no mercado B2B.
A edição mais recente é o OWASP Top 10:2021. Ela trouxe uma mudança conceitual importante em relação a 2017: as categorias passaram a ser organizadas mais por causa raiz do que por sintoma. Em vez de listar apenas o que o atacante explora, a lista de 2021 pergunta por que a falha existe, o que torna a mitigação mais estrutural e duradoura.
Os 10 riscos da edição 2021, um a um
Abaixo, cada categoria com o que ela representa e como reduzir o risco na prática. Mais adiante há uma tabela-resumo com o código, o nome e a mitigação-chave de cada item.
A01:2021 - Broken Access Control
Controle de acesso quebrado significa que um usuário consegue fazer algo que não deveria: acessar dados de outra conta, executar ações de administrador ou contornar restrições de função. O caso clássico é o IDOR (Insecure Direct Object Reference), em que trocar um identificador na URL (de /fatura/1001 para /fatura/1002) entrega o documento de outro cliente. Nos dados de 2021, esta foi a categoria com mais ocorrências, presente em 94% das aplicações testadas, e por isso saltou para o primeiro lugar. Para mitigar, negue acesso por padrão (deny by default), aplique a autorização no servidor a cada requisição (nunca confiando no front-end), centralize a lógica de permissão e force a verificação de propriedade do recurso antes de qualquer leitura ou escrita.
A02:2021 - Cryptographic Failures
Antes chamada de Sensitive Data Exposure, esta categoria foi renomeada para apontar a causa em vez do efeito: o problema raiz costuma ser uma falha de criptografia. Dados sensíveis trafegando sem TLS, senhas armazenadas com hashes fracos ou sem salt, uso de algoritmos obsoletos (MD5, SHA-1, DES) e chaves mal gerenciadas se enquadram aqui. A mitigação passa por classificar os dados sensíveis, cifrar tudo em trânsito (TLS 1.2 ou superior) e em repouso, usar algoritmos modernos e funções de derivação de senha próprias para isso (Argon2, bcrypt, scrypt), e tratar o gerenciamento de chaves como um processo formal, não um detalhe.
A03:2021 - Injection
Injeção acontece quando dados não confiáveis são interpretados como comando por um interpretador. A forma mais conhecida é a injeção de SQL, mas a categoria abrange também comandos de sistema operacional, LDAP, ORM e expressões de template. Na edição de 2021, o Cross-Site Scripting (XSS) foi absorvido por esta categoria, já que tecnicamente é injeção de script no navegador da vítima. As defesas são bem estabelecidas: use consultas parametrizadas (prepared statements), valide entradas com listas de permissão, escape a saída conforme o contexto e prefira ORMs e APIs seguras. Aprofundamos os dois principais vetores em nossos guias de SQL Injection e de XSS (Cross-Site Scripting).
A04:2021 - Insecure Design
Categoria nova em 2021 e uma das mais importantes conceitualmente. Insecure Design é uma falha de arquitetura, não de implementação: o sistema foi projetado sem considerar as ameaças, e nenhuma implementação perfeita corrige isso. Um exemplo é um fluxo de recuperação de senha baseado em perguntas secretas que qualquer um pode pesquisar. A defesa é deslocar a segurança para a esquerda (shift left): adotar modelagem de ameaças (threat modeling) desde o desenho, usar padrões de design seguros e bibliotecas de componentes confiáveis, e escrever requisitos de segurança junto com os requisitos funcionais.
A05:2021 - Security Misconfiguration
Configuração insegura é a categoria mais abrangente do dia a dia: servidores com contas e senhas padrão, recursos desnecessários habilitados, mensagens de erro que vazam stack traces, permissões de nuvem excessivamente abertas (buckets públicos) e cabeçalhos de segurança ausentes. Em 2021, o antigo XXE (XML External Entities) foi consolidado aqui, por também ser uma questão de configuração do parser. A mitigação é endurecer (harden) todos os ambientes de forma repetível e automatizada, remover o que não se usa, manter ambientes de desenvolvimento, homologação e produção consistentes e revisar configurações continuamente.
A06:2021 - Vulnerable and Outdated Components
Aplicações modernas são montadas com dezenas ou centenas de bibliotecas de terceiros, e cada uma delas pode carregar uma vulnerabilidade conhecida. Incidentes históricos como o Log4Shell mostraram o potencial destrutivo de um único componente vulnerável amplamente usado. A defesa é construir um inventário de software (SBOM), adotar Software Composition Analysis (SCA) no pipeline para alertar sobre CVEs em dependências, remover bibliotecas não usadas e manter um processo de atualização ágil, obtendo componentes apenas de fontes oficiais.
A07:2021 - Identification and Authentication Failures
Antes chamada de Broken Authentication, cobre falhas que permitem assumir a identidade de outro usuário: ausência de proteção contra força bruta e credential stuffing, sessões que não expiram, identificadores de sessão previsíveis e a falta de autenticação multifator (MFA). Para mitigar, implemente MFA, bloqueie senhas comuns e vazadas, limite tentativas de login, gere identificadores de sessão de forma segura no servidor e invalide sessões corretamente no logout e na troca de senha.
A08:2021 - Software and Data Integrity Failures
Outra categoria nova em 2021, focada em confiar em código ou dados sem verificar sua integridade. Inclui pipelines de CI/CD inseguros, atualizações automáticas sem verificação de assinatura e desserialização insegura de dados, além de ataques à cadeia de suprimentos de software (supply chain). A mitigação envolve usar assinaturas digitais para verificar a origem de software e atualizações, garantir que dependências venham de repositórios confiáveis, proteger o pipeline de build contra adulteração e revisar mudanças de código e configuração.
A09:2021 - Security Logging and Monitoring Failures
Sem registros e monitoramento adequados, um ataque pode passar despercebido por meses. Esta categoria trata da incapacidade de detectar, escalar e responder a incidentes ativos: eventos de segurança não registrados, logs sem detalhe útil, ausência de alertas e falta de integração com detecção. A defesa é registrar eventos relevantes (login, falhas de acesso, transações de alto valor) com contexto suficiente, garantir que os logs sejam protegidos contra adulteração, centralizá-los e conectá-los a um processo de resposta a incidentes com alertas acionáveis.
A10:2021 - Server-Side Request Forgery (SSRF)
SSRF entrou no Top 10 em 2021 puxada pela pesquisa de comunidade. Ocorre quando a aplicação busca um recurso a partir de uma URL fornecida pelo usuário sem validar o destino, permitindo que o atacante force o servidor a fazer requisições para sistemas internos, metadados de nuvem ou serviços que não deveriam ser alcançáveis de fora. A mitigação passa por validar e usar lista de permissão para os destinos, segmentar a rede para isolar recursos internos, desabilitar redirecionamentos e nunca enviar a resposta bruta do servidor de volta ao cliente.
Tabela-resumo do OWASP Top 10:2021
| Código | Nome | Mitigação-chave |
|---|---|---|
| A01 | Broken Access Control | Negar por padrão; autorizar no servidor a cada requisição |
| A02 | Cryptographic Failures | TLS, cifra em repouso e hashing forte de senhas (Argon2/bcrypt) |
| A03 | Injection (SQLi/XSS) | Consultas parametrizadas, validação e escape contextual de saída |
| A04 | Insecure Design | Modelagem de ameaças e padrões de design seguros (shift left) |
| A05 | Security Misconfiguration | Hardening automatizado e remoção de recursos desnecessários |
| A06 | Vulnerable and Outdated Components | SBOM, SCA no pipeline e atualização ágil de dependências |
| A07 | Identification and Authentication Failures | MFA, anti-força-bruta e gestão segura de sessão |
| A08 | Software and Data Integrity Failures | Assinaturas digitais e proteção do pipeline de CI/CD |
| A09 | Security Logging and Monitoring Failures | Log de eventos de segurança, centralização e alertas acionáveis |
| A10 | Server-Side Request Forgery (SSRF) | Lista de permissão de destinos e segmentação de rede |
O que mudou de 2017 para 2021
Quem conhece a edição anterior nota três novidades e várias reorganizações. As categorias inéditas são A04 Insecure Design, A08 Software and Data Integrity Failures e A10 SSRF, refletindo a maturidade do mercado em discutir arquitetura, cadeia de suprimentos e ataques a serviços internos. Broken Access Control subiu da quinta para a primeira posição. O Cross-Site Scripting deixou de ser categoria própria e foi absorvido por A03 Injection. O antigo A04 XML External Entities (XXE) virou parte de A05 Security Misconfiguration. E, como já mencionado, vários nomes foram ajustados para apontar a causa raiz, caso de Sensitive Data Exposure que se tornou Cryptographic Failures.
O Top 10 não é um checklist completo
Vale repetir um ponto que a própria OWASP faz questão de destacar: o Top 10 é um documento de conscientização, não um padrão de certificação nem uma lista exaustiva. Existem riscos importantes que não aparecem nele, e tratar a lista como o teto da segurança deixa classes inteiras de vulnerabilidade descobertas. Para uma verificação abrangente, a referência é o OWASP ASVS (Application Security Verification Standard), que detalha centenas de requisitos verificáveis por nível de criticidade. O Top 10 é o piso por onde todo programa começa; o ASVS é onde um programa maduro chega. Para aplicações que expõem interfaces de integração, vale ainda consultar nosso guia dedicado de segurança de APIs, que tem seu próprio Top 10 específico.
Como o Top 10 se conecta a SAST, DAST e pentest
Nenhuma técnica isolada cobre os dez riscos. A boa prática é combiná-las ao longo do ciclo de desenvolvimento. A análise estática (SAST) lê o código-fonte e é forte para encontrar padrões de injeção, segredos hardcoded e desserialização insegura antes mesmo de a aplicação rodar. A análise dinâmica (DAST) testa a aplicação em execução e cobre bem misconfiguration, cabeçalhos ausentes e falhas de autenticação que só se manifestam no ambiente real. A análise de composição (SCA) ataca diretamente o A06, alertando sobre componentes vulneráveis. Detalhamos as diferenças e quando usar cada abordagem no guia de SAST e DAST.
O que nenhuma ferramenta automática faz bem é entender a lógica de negócio. Riscos como A01 Broken Access Control e A04 Insecure Design dependem de compreender as regras da aplicação, quem deveria poder fazer o quê, e por isso exigem o olhar de um testador humano. É aí que entra o pentest manual: um especialista que reproduz o raciocínio de um atacante real, encadeia falhas e encontra os caminhos que escaneadores não enxergam. Um programa de AppSec eficaz usa ferramentas para escala e cobertura, e pentest para profundidade na lógica.
Como a Decripte trata o OWASP Top 10
A Decripte é uma empresa B2B de cibersegurança que estrutura programas de segurança de aplicações de ponta a ponta, da primeira aplicação de uma startup a portfólios com centenas de sistemas em grandes operações. Integramos SAST, SCA e DAST ao seu pipeline de CI/CD para barrar os riscos automatizáveis ainda no desenvolvimento, e conduzimos pentest manual orientado pelo OWASP Top 10 e pelo ASVS para cobrir a lógica de negócio que as ferramentas não alcançam. O resultado é entregue com remediação priorizada por risco e revalidação, para que cada correção seja confirmada e não apenas registrada.
Quer mapear onde sua aplicação está exposta aos dez riscos? Comece grátis pelo nosso Intelligence Center ou conheça os planos para um programa de AppSec sob medida para o tamanho da sua operação.
Referências
- OWASP Top 10:2021 - owasp.org/Top10
- OWASP Application Security Verification Standard (ASVS) - owasp.org
- OWASP API Security Top 10 - owasp.org/API-Security
- MITRE Common Weakness Enumeration (CWE) - cwe.mitre.org
- NIST Secure Software Development Framework (SSDF), SP 800-218 - csrc.nist.gov