OWASP Top 10: os riscos de aplicação web explicados

Fim de reunião com fornecedor, e alguém do lado do cliente pergunta: "o sistema de vocês segue o OWASP?". A resposta vem rápida, um sim seguro, e a pauta anda.

Ninguém pergunta o que aquele sim quer dizer. Ele cobre desde um scanner rodado uma vez no ano passado até um processo em que cada versão passa por teste antes de ir ao ar. A palavra é a mesma nos dois casos, e o risco para quem contratou é bem diferente.

O Top 10 é publicado pela OWASP Foundation, que se descreve como uma organização sem fins lucrativos dedicada a tornar o software mais seguro com colaboração aberta. A edição atual é a de 2025. Ela trouxe categoria nova e mudou a ordem da lista anterior, de 2021, então parte dos códigos e nomes antigos já não corresponde à lista atual.

O Top 10 é um mapa de onde os sistemas web costumam quebrar. Ele ajuda a decidir o que olhar primeiro, e quem precisa provar que uma aplicação está segura precisa de teste e de requisito verificável, coisas que a lista sozinha não entrega.

O que é a OWASP e de onde vem o Top 10

A OWASP mantém vários projetos abertos de segurança de software, e o Top 10 é o mais conhecido deles. A edição 2025 é a oitava, e a página do projeto chama a lista de padrão de referência para os riscos mais críticos de aplicação web.

A edição 2025 combina duas origens. Oito das dez categorias saem de dados doados por empresas e pesquisadores, referentes a mais de 2,8 milhões de aplicações. As outras duas saem de uma pesquisa com a comunidade de segurança. A equipe explica a escolha na introdução da edição 2025: os dados de teste são incompletos, e a pesquisa capta riscos que eles ainda não mostram bem.

Cada categoria agrupa várias fraquezas catalogadas no CWE, a lista pública de tipos de falha de software. Na edição 2025, as dez categorias somam 248 CWEs, escolhidos num universo de 589 analisados. Por isso os nomes são amplos: cada item descreve uma família de problemas com causas e controles parecidos.

As dez categorias da edição 2025, em linguagem de dono de sistema

Os nomes oficiais que a OWASP usa estão em inglês. Abaixo vão o código, o nome, uma tradução livre, um exemplo do tipo de situação e o que o time faz para reduzir o risco.

• A01 Broken Access Control (controle de acesso quebrado): o usuário chega a dado ou função que não deveria alcançar, como um cliente que consegue abrir o pedido de outro cliente. Em 2025, a SSRF (falsificação de requisição do lado do servidor) passou a fazer parte desta categoria. O time checa a permissão no servidor, em toda requisição, e nega por padrão.
• A02 Security Misconfiguration (configuração insegura): o código está certo e a instalação está errada. Um painel administrativo aberto para a internet ou uma conta padrão ainda ativa são casos típicos. A defesa é configuração revisada e igual em todos os ambientes, com o que não é usado desligado.
• A03 Software Supply Chain Failures (falhas na cadeia de suprimentos de software): o risco entra por uma biblioteca, um componente ou uma etapa de build feita por terceiros. A categoria amplia a antiga de componentes vulneráveis. O time mantém inventário do que usa e controla quem altera o pipeline, tema de cadeia de suprimentos de software.
• A04 Cryptographic Failures (falhas de criptografia): dado sensível trafega ou fica guardado sem proteção adequada, como senha armazenada de forma reversível. O controle é usar algoritmos atuais, de bibliotecas conhecidas, e criptografar o que é sensível em trânsito e em repouso.
• A05 Injection (injeção): um dado digitado pelo usuário acaba interpretado como comando por outra parte do sistema, como o banco de dados. O controle principal é separar dado de comando com consultas parametrizadas e validar a entrada no servidor. A injeção de prompt aplica a mesma ideia a sistemas com modelo de linguagem.
• A06 Insecure Design (design inseguro): a falha nasce no desenho, antes da primeira linha de código. Um fluxo de recuperação de senha que confia numa pergunta fácil de adivinhar é um exemplo. Corrigir a implementação não basta, e o time precisa de modelagem de ameaça e de requisito de segurança desde a concepção.
• A07 Authentication Failures (falhas de autenticação): o sistema confirma mal quem é o usuário. Ele aceita senha fraca, não limita tentativas ou deixa a sessão aberta por tempo demais. A redução vem de autenticação multifator, limite de tentativas e expiração de sessão.
• A08 Software or Data Integrity Failures (falhas de integridade de software ou dados): a aplicação aceita como confiável algo que ninguém verificou, como uma atualização automática sem assinatura. O controle é conferir assinatura e origem antes de usar o pacote ou o dado.
• A09 Security Logging and Alerting Failures (falhas de registro e alerta): o ataque acontece e ninguém fica sabendo, porque o sistema não registra o evento ou registra sem avisar ninguém. O nome fala em alerta, além de registro. O time define quais eventos geram aviso e quem recebe cada um.
• A10 Mishandling of Exceptional Conditions (tratamento inadequado de condições excepcionais): é a categoria nova de 2025. Ela cobre o que acontece quando algo sai do previsto, como erro sem tratamento ou sistema que libera o acesso quando a própria checagem de permissão falha. A orientação da página da categoria é tratar o erro onde ele ocorre, desfazer transações incompletas e falhar fechado.

Agrupadas, as dez cabem numa tabela de seis linhas:

O que o Top 10 não é

A OWASP chama o Top 10 de documento de conscientização. No texto sobre como montar um programa de segurança de aplicação, a fundação diz que, para quem programa ou testa, a lista é o mínimo e um ponto de partida. Para quem quer adotar um padrão, ela recomenda o ASVS (Application Security Verification Standard), porque ele foi desenhado para ser verificável e testado.

Nenhuma empresa é certificada no Top 10, e nenhuma aplicação passa ou reprova nele. A lista também deixa de fora o risco que é só seu, como uma regra de desconto que alguém consegue usar duas vezes. Ela trata de aplicação web, então rede, estação de trabalho e golpe por telefone ficam fora do recorte.

Muita empresa inverte o uso. Em vez de orientar onde testar primeiro, a lista vira uma caixa marcada no questionário de segurança, e o assunto parece resolvido.

A lista de riscos para LLM e IA generativa

A OWASP mantém uma lista separada para aplicações com modelo de linguagem, o Top 10 for LLMs and Gen AI Apps, também em edição 2025. O primeiro item é injeção de prompt. A lista inclui ainda vazamento de informação sensível, agência excessiva (quando o agente pode fazer mais do que a tarefa exige) e consumo sem limite de recursos.

Quem tem chatbot ou agente ligado a sistema interno precisa das duas listas. A de aplicação web continua valendo para tudo o que está em volta do modelo: login, API, banco e painel. A de LLM cobre o comportamento do modelo e das ferramentas que ele chama em nome do usuário.

Como usar o Top 10 em contrato e em pentest

Em contrato, a frase "o sistema segue o OWASP Top 10" quase não obriga a nada, porque não diz como verificar. Uma cláusula útil pede evidência. O fornecedor entrega um relatório de teste que diga, categoria por categoria, o que foi verificado, com qual método e o que ficou pendente. Para requisitos mais finos, o contrato cita um nível do ASVS, que tem itens verificáveis um a um. O contrato também fixa o prazo de correção de falha crítica depois do aviso.

Num pentest, a lista ajuda a definir escopo e a ler o relatório. Peça que os achados venham classificados pelas categorias do OWASP Top 10 de 2025. Assim você enxerga quando o problema se repete na mesma família, como controle de acesso, e trata a causa em vez de cada achado isolado. Só não aceite o Top 10 como escopo inteiro. Um bom teste também olha a regra de negócio do seu sistema, que nenhuma lista genérica conhece.

A proteção na borda entra depois. Um WAF barra parte do tráfego malicioso, sobretudo tentativas de injeção, mas não corrige controle de acesso mal desenhado. Ele não tem como saber que aquele cliente não deveria ver aquele pedido.

Como começar numa empresa pequena

1. Liste as aplicações expostas na internet. Site, loja, portal do cliente, painel administrativo e API entram na conta. Sem inventário, não há o que mapear.
2. Escolha as categorias que mais pesam no seu caso. Para quase todo sistema com login, controle de acesso (A01) e autenticação (A07) entram de saída.
3. Pergunte ao time ou ao fornecedor como cada uma é tratada hoje. A resposta precisa citar um controle concreto. "Seguimos boas práticas" não serve como resposta.
4. Inventarie bibliotecas e componentes. Um scanner de dependências roda no pipeline e aponta versão com falha conhecida, o que cobre parte da A03.
5. Ligue o alerta antes de comprar ferramenta nova. Defina quais eventos geram aviso, como muitas falhas de login seguidas, e quem recebe.
6. Contrate um teste com escopo escrito antes de cada mudança grande. Use as categorias como roteiro e acrescente as regras de negócio do sistema.
7. Leve os achados para a fila de correção. A gestão de vulnerabilidades decide o que corrigir primeiro, com dono e prazo.

O que a edição 2025 mostra

A ordem da lista indica onde os testes mais encontram problema. Em 2025, o primeiro lugar ficou com controle de acesso, já somado à SSRF, e a configuração insegura veio logo atrás.

A categoria nova, A10, dispensa técnica sofisticada. Ela descreve o sistema que, diante de um erro na própria checagem de permissão, libera o acesso em vez de negar.