OWASP Top 10: as principais falhas de aplicações web
Um consenso de mercado sobre onde as aplicações mais falham. Serve como mapa de risco, não como substituto de um teste.
O OWASP Top 10 é a lista mais conhecida de riscos de segurança em aplicações web. Ela é mantida pela OWASP, uma comunidade aberta e sem fins lucrativos, e resume as dez categorias de falha que mais aparecem e que mais causam impacto. A lista não é uma norma nem uma certificação. Ela é um consenso de mercado que serve de ponto de partida para quem desenvolve, testa ou contrata avaliações de segurança de software.
Este guia explica cada uma das dez categorias da edição de 2021 em linguagem defensiva, com o significado do risco e o caminho de mitigação. O objetivo é dar um mapa útil para priorizar, sem tratar a lista como uma checklist mágica. Passar por todos os itens do Top 10 reduz risco, mas não substitui o teste manual de uma aplicação, que encontra falhas de lógica que nenhuma lista genérica prevê.
O que o OWASP Top 10 é e o que não é
O Top 10 é uma lista de categorias de risco, não de vulnerabilidades específicas. Cada item agrupa muitas falhas relacionadas sob um mesmo tema. A lista é revisada periodicamente com base em dados reais de aplicações analisadas, o que faz dela um retrato de onde o risco costuma se concentrar. Serve como linguagem comum entre times de desenvolvimento, segurança e gestão.
O que o Top 10 não é: uma garantia de cobertura completa. Uma aplicação pode passar por todos os dez temas e ainda ter uma falha grave de lógica de negócio, que só aparece com análise de contexto. Por isso a lista é melhor usada como base de conscientização e como parte de um programa maior de segurança de aplicações, que inclui revisão de código, testes automatizados e pentest.
Da primeira à quinta categoria
- Quebra de controle de acesso: usuários acessam dados ou ações além do que deveriam. É o risco mais comum. Mitiga-se com autorização verificada no servidor, negação por padrão e testes de acesso entre perfis.
- Falhas criptográficas: dados sensíveis expostos por falta ou uso incorreto de criptografia. Mitiga-se com criptografia em trânsito e em repouso, algoritmos atuais e gestão adequada de chaves e segredos.
- Injeção: entrada não validada muda o significado de uma consulta ou comando, como em SQL injection. Mitiga-se com consultas parametrizadas, validação de entrada e uso de bibliotecas seguras.
- Design inseguro: falhas que nascem na arquitetura, não na implementação. Mitiga-se com modelagem de ameaças, padrões seguros e requisitos de segurança desde o início do projeto.
- Configuração incorreta de segurança: serviços expostos, permissões amplas e padrões inseguros deixados como vieram. Mitiga-se com baselines de hardening, revisão de configuração e remoção do que não é usado.
Da sexta à décima categoria
- Componentes vulneráveis e desatualizados: bibliotecas e dependências com falhas conhecidas. Mitiga-se com inventário de dependências, análise de composição e atualização contínua.
- Falhas de identificação e autenticação: sessões e credenciais mal protegidas. Mitiga-se com segundo fator, política de senha sensata, proteção contra força bruta e gestão segura de sessão.
- Falhas de integridade de software e dados: atualizações e dados aceitos sem verificação de origem. Mitiga-se com assinatura, verificação de integridade e cuidado com a cadeia de fornecimento de software.
- Falhas de registro e monitoramento de segurança: ataques que passam sem deixar rastro ou sem gerar alerta. Mitiga-se com logs relevantes, centralização e casos de uso de detecção.
- Falsificação de requisição no lado do servidor (SSRF): o servidor é induzido a acessar destinos internos indevidos. Mitiga-se com validação de destino, listas de permissão e segmentação de rede.
A ordem das categorias reflete uma combinação de frequência, facilidade de exploração e impacto. Quebra de controle de acesso lidera porque aparece em muitas aplicações e permite acesso indevido a dados e funções. Isso ajuda a priorizar: em uma primeira leitura, controle de acesso, criptografia e injeção costumam ser onde vale concentrar atenção.
Prevenção na prática, por classe de risco
As categorias ficam mais concretas quando viram decisão de código. Os exemplos a seguir são defensivos e mostram o padrão seguro, não o ataque. A ideia é que a escolha certa vire hábito e a falha deixe de nascer.
Injeção: consulta parametrizada
A injeção acontece quando dados do usuário se misturam ao comando. A defesa é separar comando de dado com consultas parametrizadas, em que a entrada nunca é interpretada como parte da instrução.
# Evite: montar a consulta concatenando entrada do usuário
# Prefira: parâmetros ligados, tratados sempre como dado
cursor.execute(
"SELECT id, nome FROM usuarios WHERE email = %s",
(email_informado,),
)Controle de acesso: negar por padrão
A quebra de controle de acesso costuma vir de verificar permissão no lugar errado ou de assumir que esconder um botão basta. A defesa é verificar autorização no servidor, a cada requisição, negando por padrão e liberando apenas o que a regra permite.
# O recurso pertence a quem pede? Verifique sempre no servidor.
def abrir_documento(usuario, documento_id):
doc = repositorio.buscar(documento_id)
if doc is None or doc.dono_id != usuario.id:
raise AcessoNegado() # nega por padrão
return docCabeçalhos de segurança e configuração
Parte da configuração incorreta se resolve com cabeçalhos de resposta que instruem o navegador a se proteger. Eles reduzem a superfície de ataques como injeção de conteúdo e uso indevido do site em quadros de terceiros. São uma camada a mais, não um substituto da correção no código.
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=63072000; includeSubDomains
Referrer-Policy: no-referrerComo usar o Top 10 na prática
A melhor forma de usar o Top 10 é integrá-lo ao ciclo de desenvolvimento, e não tratá-lo como uma auditoria isolada no fim. Ele serve para orientar requisitos de segurança, revisões de código e a configuração das ferramentas de teste. Quando os times conhecem as categorias, muitas falhas deixam de nascer, porque a decisão segura vira parte do desenho.
- Usar as categorias como requisitos de segurança no desenvolvimento
- Configurar ferramentas de SAST, SCA e DAST alinhadas ao Top 10
- Priorizar controle de acesso, criptografia e injeção em uma primeira leitura
- Complementar com modelagem de ameaças para o design inseguro
- Validar com pentest o que ferramentas e listas não alcançam
O que existe além do Top 10
O Top 10 é a porta de entrada, não o fim da linha. A própria OWASP mantém projetos mais profundos para quando a conscientização precisa virar requisito verificável. Conhecer esse ecossistema ajuda a não parar na lista de dez temas.
- ASVS: um padrão de requisitos de segurança de aplicações, útil para definir o nível de rigor esperado e orientar testes
- Cheat Sheets: guias objetivos de como implementar cada defesa de forma correta
- Guias de teste: metodologia para avaliar aplicações de forma estruturada
- API Security Top 10: uma lista dedicada aos riscos específicos de APIs
Onde o Top 10 diz onde o risco costuma estar, o ASVS diz o que exigir e como verificar. Times mais maduros usam a lista para conscientizar e o ASVS para transformar segurança em critério de aceite, algo que conversa bem com a verificação automatizada no pipeline.
Checklist prático
- Verificar autorização no servidor para todas as ações sensíveis
- Aplicar criptografia em trânsito e em repouso com chaves geridas
- Usar consultas parametrizadas e validar entradas
- Incluir requisitos de segurança no design da aplicação
- Aplicar baseline de hardening e revisar configuração
- Inventariar dependências e atualizar componentes vulneráveis
- Proteger autenticação com segundo fator e gestão de sessão
- Verificar integridade de atualizações e da cadeia de software
- Gerar logs relevantes e casos de uso de detecção
- Validar destinos de requisição para evitar SSRF
- Aplicar cabeçalhos de segurança na resposta ao navegador
- Definir requisitos verificáveis de segurança, por exemplo com o ASVS
Boas práticas
- Trate o Top 10 como mapa de risco, não como garantia de cobertura
- Integre as categorias ao ciclo de desenvolvimento, não ao fim
- Priorize controle de acesso, o risco mais comum da lista
- Combine SAST, SCA e DAST com revisão humana
- Use modelagem de ameaças para tratar o design inseguro
- Transforme as categorias em requisitos verificáveis, não só em avisos
- Valide com pentest as falhas de lógica que a lista não prevê
Erros comuns
Tratar o Top 10 como checklist que garante segurança
Falsa sensação de cobertura, com falhas de lógica ainda abertas.
Confiar apenas em ferramentas automatizadas
Falhas de autorização e de negócio passam sem serem testadas.
Deixar segurança para o fim do desenvolvimento
Correções caras e falhas de design difíceis de reverter.
Ignorar dependências e componentes desatualizados
Vulnerabilidades conhecidas expostas por bibliotecas antigas.
Parar a maturidade no Top 10 e nunca evoluir para requisitos
A segurança fica na conscientização e não vira critério de aceite testável.
Quando procurar apoio especializado
O serviço de Segurança de Aplicações da GUARDIASEC avalia aplicações web contra as categorias do OWASP Top 10 e além delas, com teste manual que encontra falhas de lógica de negócio, priorização por risco e recomendações de correção objetivas.
Perguntas frequentes
O OWASP Top 10 é uma norma ou certificação?
Nenhum dos dois. O OWASP Top 10 é uma lista de referência mantida pela comunidade OWASP, que resume as categorias de risco mais comuns em aplicações web. Ele não impõe requisitos obrigatórios nem oferece certificação. Serve como consenso de mercado e ponto de partida para orientar desenvolvimento, testes e contratação de avaliações de segurança de software.
Passar por todo o OWASP Top 10 deixa a aplicação segura?
Reduz risco, mas não garante segurança. A lista cobre categorias comuns, e uma aplicação pode tratar todas elas e ainda ter uma falha grave de lógica de negócio, que só aparece com análise de contexto. Por isso o Top 10 é melhor usado como base dentro de um programa maior, que inclui revisão de código, testes automatizados e pentest com validação manual.
Qual categoria do OWASP Top 10 é a mais comum?
Na edição de 2021, a quebra de controle de acesso lidera a lista. Ela aparece quando um usuário consegue acessar dados ou executar ações além do que sua permissão deveria autorizar. A mitigação passa por verificar autorização no servidor, adotar negação por padrão e testar o acesso entre diferentes perfis de usuário, e não apenas confiar em esconder botões na interface.
Com que frequência o OWASP Top 10 é atualizado?
A OWASP revisa a lista periodicamente, com base em dados de aplicações analisadas e na percepção da comunidade. Não há um calendário curto e fixo; entre uma edição e outra passam alguns anos. Neste guia, a referência é a edição de 2021. O valor da lista não está em ser a mais recente, e sim em orientar prioridade: o que muda entre edições costuma ser a ordem e o agrupamento, não a natureza defensiva de cada tema.
Qual a diferença entre o OWASP Top 10 e o ASVS?
O Top 10 é uma lista de conscientização que aponta onde o risco costuma se concentrar. O ASVS é um padrão de requisitos de segurança de aplicações, pensado para definir e verificar o nível de rigor esperado. Um serve para alertar e priorizar; o outro, para transformar segurança em critério de aceite testável. Times mais maduros usam os dois: o Top 10 para conscientizar e o ASVS para exigir e validar.
O OWASP Top 10 vale para APIs?
Em parte. Muitas categorias, como quebra de controle de acesso e injeção, também afetam APIs. Mas APIs têm riscos próprios de autorização em nível de objeto e de função, que a OWASP trata em um projeto separado, o API Security Top 10. Para quem expõe APIs, o caminho é usar as duas listas em conjunto, porque a lista voltada a aplicações web não cobre sozinha tudo o que uma API precisa.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.