OWASP Top 10: o que é e quais são as 10 vulnerabilidades

A OWASP é uma fundação sem fins lucrativos que mantém listas públicas das falhas de segurança mais críticas em software. O OWASP Top 10 é a mais conhecida delas: as dez categorias de vulnerabilidade que mais aparecem em aplicações web, revisadas a cada poucos anos. Existe também um Top 10 separado para machine learning e outro para aplicações que usam LLM, porque as falhas são diferentes.

O que é a OWASP?

A OWASP, sigla de Open Worldwide Application Security Project, é uma fundação sem fins lucrativos que publica material aberto sobre segurança de software: listas de risco, guias de teste, folhas de referência de código seguro e ferramentas. Nada do que ela produz é pago ou fechado, e é por isso que as listas dela viraram referência em auditoria, contrato e norma interna de empresa.

A OWASP mantém mais de uma lista de risco. A mais conhecida é a de aplicações web, mas existem edições separadas para machine learning e para aplicações que usam LLM, porque os ataques nesses sistemas não se parecem com os de um formulário web.

O que é o OWASP Top 10 e por que ele ainda importa em 2026

O OWASP Top 10 é atualizado periodicamente com base em dados reais de milhares de aplicações analisadas por empresas de segurança parceiras do projeto. A lista completa e detalhada está disponível na documentação oficial do OWASP Top Ten, que também mantém o Cheat Sheet Series com exemplos de código seguro para cada categoria. Mesmo com o avanço de frameworks que já mitigam parte desses problemas por padrão, os dez riscos continuam aparecendo em auditorias porque nascem de decisões de arquitetura, não de bugs isolados.

Quais são as 10 vulnerabilidades do OWASP Top 10?

A edição vigente é a de 2025, e estas são as dez categorias, na ordem publicada (fonte: owasp.org/Top10/2025, consultado em 28/08/2026):

1. A01 Broken Access Control, controle de acesso quebrado: o usuário alcança dado ou ação que não é dele.
2. A02 Security Misconfiguration, configuração insegura: padrão de fábrica, permissão larga, serviço exposto.
3. A03 Software Supply Chain Failures, falhas na cadeia de suprimento: dependência, imagem e artefato de build comprometidos.
4. A04 Cryptographic Failures, falhas de criptografia: dado sensível em claro, algoritmo fraco, chave mal guardada.
5. A05 Injection, injeção: entrada do usuário interpretada como comando, de SQL a shell.
6. A06 Insecure Design, projeto inseguro: a falha está na regra de negócio, não no código.
7. A07 Authentication Failures, falhas de autenticação: sessão, senha e recuperação de conta.
8. A08 Software or Data Integrity Failures, falhas de integridade: atualização e desserialização sem verificação.
9. A09 Security Logging and Alerting Failures, log e alerta insuficientes: o ataque acontece e ninguém vê.
10. A10 Mishandling of Exceptional Conditions, tratamento errado de exceção: o sistema falha de forma insegura.

As seções abaixo detalham cada categoria na prática, com exemplo e prevenção, e seguem a nomenclatura das edições anteriores da lista. Vários nomes mudaram de 2017 para cá: XXE e CSRF, por exemplo, foram absorvidos por outras categorias em vez de sumirem como problema. O conceito continua valendo; o que mudou foi a etiqueta.

Injection: quando dados do usuário viram código

Injection acontece quando dados enviados pelo usuário são inseridos diretamente em uma query, comando de sistema ou interpretador sem validação. O resultado mais comum é o SQL injection, que pode expor ou apagar uma tabela inteira do banco de dados.

A forma de evitar é simples e não tem exceção: nunca concatene dados do usuário em queries. Use prepared statements (ou parametrized queries): você define a estrutura da query com placeholders e passa os dados do usuário como parâmetros separados. O banco trata esse conteúdo como dado, nunca como código executável.

Aplicações que usam agentes de IA enfrentam uma variação moderna do mesmo problema: o prompt injection em agentes de IA, em que texto malicioso inserido no prompt tenta sequestrar as instruções do modelo. O princípio de defesa é o mesmo do injection clássico, tratar entrada externa sempre como dado não confiável.

Autenticação quebrada: senhas e sessões vulneráveis

Autenticação quebrada significa que um atacante consegue logar com credenciais inválidas, contornar o processo de login ou sequestrar a sessão de outro usuário.

Falhas comuns incluem armazenar senhas em texto plano, sessões que nunca expiram e tokens sem validação de assinatura. Nesses cenários, uma ferramenta automatizada testa milhares de combinações de senha por segundo até invadir uma conta.

Boas práticas de autenticação

• Hash de senha com algoritmo lento, como bcrypt ou Argon2, nunca MD5 ou SHA simples.
• Sessões com expiração definida e renovação segura.
• Tokens assinados e validados a cada requisição.
• Rate limiting em endpoints de login para dificultar força bruta.

Exposição de dados sensíveis

Toda aplicação armazena algum dado sensível: senhas, tokens de API, números de cartão, documentos pessoais. Se um invasor acessa o sistema, esses dados precisam estar protegidos, não disponíveis em texto plano.

Erros frequentes incluem dados sensíveis mantidos sem criptografia em memória ou banco, logs que registram senhas por engano, backups sem criptografia e tráfego trafegando em HTTP em vez de HTTPS.

A correção passa por HTTPS obrigatório em toda a aplicação, criptografia de dados sensíveis em repouso, segredos configurados em variáveis de ambiente (nunca hardcoded no código) e logs que nunca registram senhas ou tokens completos.

XML External Entities (XXE)

Se sua aplicação processa arquivos XML, um atacante pode inserir referências externas maliciosas que exploram o parser XML. O resultado vai da leitura de arquivos sensíveis do servidor até negação de serviço.

É um risco menos comum hoje, já que muitas APIs modernas usam JSON, mas continua crítico em sistemas legados ou integrações B2B baseadas em XML. A correção é direta: desabilite o processamento de external entities no parser XML, geralmente uma única linha de configuração.

Controle de acesso quebrado (Broken Access Control)

Controle de acesso correto garante que o usuário A veja apenas os dados de A, o usuário B veja apenas os de B, e que apenas administradores acessem funções administrativas. Quando essa regra falha, qualquer usuário autenticado pode acessar dados de outra conta.

Erros comuns incluem validar permissão apenas no frontend (o backend aceita a requisição de qualquer forma) e usar IDs sequenciais que permitem enumerar registros de outros usuários trocando um número na URL.

A correção exige verificar permissão no servidor para toda ação sensível, usar identificadores não sequenciais (UUID em vez de ID incremental) e aplicar whitelist de recursos permitidos por papel de usuário. O mesmo princípio de “verificar antes de agir” aparece em sistemas de IA que executam ações automatizadas: veja como o human in the loop em agentes de IA define pontos de pausa para aprovação humana antes de uma ação crítica ser executada.

Configuração de segurança incorreta

Acontece quando uma aplicação vai para produção com configurações de ambiente de desenvolvimento: modo debug ativo, senhas padrão não trocadas, stack traces expostos ao usuário final e headers HTTP que revelam a tecnologia usada no backend.

A correção passa por manter configurações separadas entre desenvolvimento e produção, usar senhas e segredos fortes e únicos por ambiente, desabilitar debug em produção e remover headers que vazam informação de infraestrutura. Quem faz deploy self-hosted também precisa gerenciar bem essas variáveis: o guia de n8n self-hosted no Docker mostra como isolar segredos e configurações sensíveis fora da imagem da aplicação.

Cross-Site Scripting (XSS): injetando JavaScript no navegador de outro usuário

No XSS, o atacante insere JavaScript malicioso em um campo do site. Quando outro usuário visualiza essa página, o script executa no navegador dele, permitindo roubo de cookies de sessão, redirecionamento para sites falsos ou phishing.

O erro típico é aceitar HTML ou JavaScript em formulários sem nenhum filtro. A correção envolve escapar todo dado do usuário antes de exibi-lo no HTML, aplicar Content Security Policy para restringir quais scripts podem rodar na página e sanitizar HTML apenas quando a aplicação realmente precisa aceitar formatação rica.

Cross-Site Request Forgery (CSRF): forçando ações sem consentimento

No CSRF, o usuário está autenticado em um sistema (por exemplo, um banco) e, ao visitar um site malicioso em outra aba, esse site dispara uma requisição para o banco se passando pelo usuário logado, sem que ele perceba.

A defesa correta combina tokens CSRF exclusivos por sessão e requisição, validação dos headers Origin e Referer no servidor, e cookies configurados com o atributo SameSite.

Componentes com vulnerabilidades conhecidas

Uma aplicação moderna depende de dezenas ou centenas de bibliotecas de terceiros. Basta uma delas ter uma vulnerabilidade conhecida e publicada para que um atacante explore essa falha através da sua aplicação, mesmo sem tocar no código próprio.

A prevenção envolve manter dependências sempre atualizadas, usar ferramentas de detecção automática de vulnerabilidades conhecidas (como Dependabot, Snyk ou o próprio npm audit) e remover pacotes que não são mais utilizados no projeto.

Logging e monitoramento insuficientes

Um padrão recorrente em investigações de incidentes de segurança: a equipe só descobre o ataque semanas depois, porque não havia logs suficientes, ou porque os logs existentes foram sobrescritos em poucas horas.

A correção exige registrar eventos de segurança relevantes (login, falha de autenticação, mudança de permissão), armazenar esses logs em local seguro e separado da aplicação, e monitorar em tempo real por padrões anômalos que indiquem tentativa de invasão.

O que é o OWASP Top 10 para machine learning?

É uma lista separada da web, o OWASP Machine Learning Security Top 10, que cataloga os ataques específicos de sistemas que aprendem com dados. Ela existe porque nenhuma das dez categorias web descreve o que acontece quando alguém envenena o conjunto de treino ou reconstrói o dado original a partir das respostas do modelo.

Na versão 0.3, edição 2023, consultada em 28/08/2026, as dez entradas são: manipulação de entrada (ML01), envenenamento de dados (ML02), inversão de modelo (ML03), inferência de pertencimento (ML04), roubo de modelo (ML05), ataque à cadeia de suprimento de IA (ML06), ataque via transferência de aprendizado (ML07), enviesamento do modelo (ML08), ataque à integridade da saída (ML09) e envenenamento do modelo (ML10). Atenção a um detalhe que a maioria dos artigos omite: o próprio projeto marca essa versão como rascunho em modificação frequente, então cite a fonte oficial com a data em que você consultou, e não uma cópia de terceiro.

Se o seu sistema usa LLM, e não um modelo treinado por você, a lista que se aplica é outra: o OWASP Top 10 for LLM Applications, edição 2025. Ela abre com injeção de prompt (LLM01) e cobre vazamento de informação sensível, cadeia de suprimento, envenenamento de dado e de modelo, tratamento inseguro da saída, agência excessiva, vazamento do prompt de sistema, fraquezas de vetor e embedding, desinformação e consumo sem limite. As três listas convivem: uma aplicação com LLM em produção normalmente precisa das três.

Erros comuns ao aplicar o OWASP Top 10

O primeiro erro é tratar segurança como etapa final: construir a aplicação inteira e só depois pensar em proteção. O correto é considerar cada item do Top 10 desde o design da arquitetura, não como um checklist de última hora.

O segundo erro é acreditar que “ninguém vai atacar minha aplicação”. Talvez nenhuma pessoa específica ataque, mas bots automatizados varrem a internet constantemente em busca de falhas conhecidas, sem distinguir o tamanho ou a relevância do alvo.

O terceiro erro é confiar em segurança por obscuridade, esperando que uma falha não seja descoberta só porque não foi divulgada. A postura correta é assumir que qualquer vulnerabilidade será encontrada eventualmente e proteger o sistema de qualquer forma.

Perguntas frequentes

O que é o OWASP Top 10?

É a lista das dez categorias de vulnerabilidade mais críticas em aplicações web, mantida pela OWASP com base em dados reais coletados de milhares de sistemas em produção.

Quanto custa implementar as práticas do OWASP Top 10?

Custa pouco quando aplicado desde o início do projeto, e custa muito mais quando uma falha de segurança é descoberta depois que a aplicação já está em produção com dados reais de usuários.

Preciso de um especialista em segurança para seguir o OWASP Top 10?

Para sistemas críticos, sim, vale contratar uma auditoria especializada. Para a maioria das aplicações, seguir corretamente as dez categorias já reduz drasticamente o risco de invasão.

Como saber se minha aplicação já foi comprometida?

Só é possível saber com logs e monitoramento configurados corretamente. Sem registro de eventos de segurança, não há como identificar acessos indevidos, então a configuração de alertas para atividades anormais é essencial.

O OWASP Top 10 cobre segurança de aplicações que usam IA?

Cobre os fundamentos, mas aplicações com agentes de IA têm riscos adicionais específicos, como o prompt injection, que exigem camadas extras de validação além dos dez itens clássicos.

• Leia também:
• FastAPI do zero: criando uma API REST em Python em menos de uma hora
• PostgreSQL vs MongoDB: como escolher o banco certo para cada projeto
• Data contracts na prática: como evitar que dados quebrados derrubem sua IA

Arrume seu OWASP Top 10 hoje

Faça uma checagem simples: sua aplicação usa prepared statements? Senhas com hash forte? HTTPS em todas as rotas? Controle de acesso validado no servidor, não só no frontend?

Para cada resposta negativa, priorize a correção pelos itens de maior impacto, começando por injection e controle de acesso, que costumam causar os incidentes mais graves.