OWASP Top 10 2025: o que muda e que riscos um scanner consegue detetar

O que é o OWASP Top 10 2025?

O OWASP Top 10 2025 é uma classificação de dez categorias de risco para aplicações web, cada uma a agrupar fraquezas CWE relacionadas. Para esta edição, a OWASP analisou 589 CWE e ficou com 248 distribuídas pelas dez categorias, com um máximo de 40 por categoria. Oito categorias vêm de dados de testes cedidos por empresas como Semgrep, Sonar, Veracode, Contrast Security ou Bugcrowd. As outras duas vêm de um inquérito à comunidade, porque a OWASP considera que os dados, sozinhos, estão incompletos.

As equipas de segurança usam a lista como vocabulário comum. Formações, listas de verificação de revisão de código, relatórios de scanners e evidências de auditoria costumam estar organizados pelas suas categorias, e é por isso que cada nova edição se reflete nas ferramentas, nas políticas e nas auditorias.

Quais são as dez categorias?

As dez categorias do OWASP Top 10 2025 são Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures e Mishandling of Exceptional Conditions. A OWASP publica-as em inglês, e é assim que as equipas as citam.

O que mudou em relação à lista de 2021?

Para uma equipa de desenvolvimento contam quatro mudanças: a cadeia de fornecimento ganha categoria própria, a SSRF passa para o controlo de acesso, o tratamento de erros torna-se categoria e a configuração insegura sobe para segundo.

• Software Supply Chain Failures (A03). A categoria de 2021, Vulnerable and Outdated Components, tratava das CVE conhecidas nas tuas dependências. A de 2025 cobre falhas ou comprometimentos no processo de construir, distribuir ou atualizar software, e a OWASP nomeia expressamente o servidor de build e a CI/CD entre o que é preciso proteger. Analisar o lockfile já não chega: a pipeline que constrói o teu código também entra no perímetro. Segundo as notas da OWASP, é a categoria com a taxa de incidência média mais alta das dez.
• A SSRF entra em Broken Access Control (A01). A falsificação de pedidos do lado do servidor era a A10 em 2021. Agora conta como uma das 40 fraquezas do controlo de acesso falhado.
• Mishandling of Exceptional Conditions (A10). A nova categoria trata de programas que não conseguem prevenir, detetar nem responder a situações invulgares e imprevisíveis. Entre as suas 24 fraquezas: mensagens de erro que expõem dados sensíveis (CWE-209), desreferências de ponteiro NULL (CWE-476) e código que falha em aberto em vez de falhar de forma segura (CWE-636).
• Security Misconfiguration (A02) sobe do quinto para o segundo lugar. A definição da OWASP passa a nomear os serviços cloud ao lado dos sistemas e aplicações mal configurados.

Mudam dois nomes: Identification and Authentication Failures passa a Authentication Failures, e Security Logging and Monitoring Failures passa a Security Logging and Alerting Failures. A negação de serviço, rebatizada Lack of Application Resilience, fica na secção de «próximos passos» da OWASP, fora das dez.

Que scanner open source deteta cada risco?

Os scanners estáticos open source cobrem de forma ampla Injection e Cryptographic Failures, outras seis categorias em parte, e pouco de Insecure Design e de Security Logging and Alerting Failures. A tabela é a nossa leitura do alcance documentado de cada ferramenta face às páginas de categoria da OWASP, a 13 de novembro de 2026.

O Opengrep, o fork do Semgrep com licença LGPL-2.1, cobre mais de 30 linguagens e corre as regras do Semgrep sem alterações. O seu README descreve uma análise de taint dentro de um ficheiro, por isso a linha de Injection diz «fluxos que atravessam vários ficheiros». O Trivy lê dependências, infraestrutura como código, segredos e licenças, e o nosso teste de ferramentas SCA open source mostra o que ele e o OSV-Scanner encontram num lockfile real. O Gitleaks encontra palavras-passe, chaves de API e tokens em ficheiros e no histórico do git; as credenciais escritas no código (CWE-798) pertencem à A07 na lista de 2025, e a nossa comparação de scanners de segredos open source trata-o a fundo. O zizmor é um analisador estático para GitHub Actions, com auditorias como template-injection, unpinned-uses, dangerous-triggers, excessive-permissions e cache-poisoning, que chegam à A03 e à A08.

Nenhuma destas ferramentas vê um pacote malicioso que ainda não tem aviso de segurança, a brecha por onde passa o slopsquatting, o ataque aos nomes de pacotes que um modelo de IA inventa.

Porque é que os scanners não veem o risco número um?

Os scanners estáticos falham o núcleo de Broken Access Control porque a falha é um controlo que falta, e um controlo que falta não tem padrão. Um scanner consegue seguir a entrada do utilizador até uma função perigosa. Não tem nenhuma fonte para a regra de que uma fatura pertence a um cliente.

Os conjuntos de regras mostram-no. A 13 de novembro de 2026 contámos as regras do conjunto comunitário do Opengrep, uma cópia das regras do Semgrep de janeiro de 2025: 2007 regras, das quais 1354 têm uma categoria OWASP de 2021. Injection tem 384. Broken Access Control tem 228, mas 114 delas verificam permissões de recursos cloud, sobretudo em Terraform, e outras cobrem path traversal, CSRF e redirecionamentos abertos. As três fraquezas que descrevem a autorização em si, CWE-639 (contornar a autorização com uma chave controlada pelo utilizador), CWE-862 (autorização em falta) e CWE-863 (autorização incorreta), aparecem em quatro regras. Três leem código de aplicação, cada uma para uma única framework: um find sem âmbito em Ruby on Rails, um controlador ASP.NET Core sem atributo de autorização e operações nativas de dados em Salesforce Apex. Detetam um controlo que falta; nenhuma sabe dizer se um controlo presente é o certo.

A OWASP já o escrevia em 2017: as ferramentas SAST e DAST conseguem detetar a ausência de controlo de acesso, mas não conseguem verificar se funciona quando está presente. Eis como isso fica numa rota Express:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

A rota exige login, a consulta é parametrizada e a entrada nunca chega a uma função perigosa. O scanner não tem nada para assinalar. E, no entanto, qualquer cliente com sessão iniciada pode ler qualquer fatura mudando o número no URL: uma referência direta insegura a objetos, ou IDOR. A correção é uma condição, where: { id: req.params.id, customerId: req.user.customerId }, e só a consegue escrever quem sabe que as faturas pertencem aos clientes.

Insecure Design fica ainda mais longe. A página da OWASP di-lo sem rodeios: um design inseguro não se corrige com uma implementação perfeita, porque os controlos necessários nunca foram criados. Um carrinho que aceita uma quantidade negativa passa em todos os scanners, como mostra o nosso relato do carrinho a 0 €. Tratamos toda a família em falhas de lógica de negócio no código gerado por IA.

Como se testa o controlo de acesso?

O controlo de acesso testa-se com um teste que tenta a ação proibida e espera uma recusa, um por perfil e por cada objeto que tem dono. A página de 2025 da OWASP pede exatamente isso: programadores e QA devem incluir testes funcionais do controlo de acesso nos seus testes unitários e de integração.

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Este teste é ao mesmo tempo a prova e a proteção. Antes da correção falha, o que prova que a falha existe no teu código e não em teoria. Depois da correção passa, e fica na suite para que a próxima alteração não volte a abrir o buraco. O que custa é saber que objetos pertencem a quem, precisamente o que o scanner não sabe.

Três hábitos cobrem boa parte do terreno:

1. Recusar por omissão. Cada rota nova nasce fechada, e o acesso é concedido por um controlo explícito que nomeia o dono ou o perfil.
2. Limitar cada consulta ao utilizador. Procura os registos através do utilizador ou do tenant atual, nunca com um identificador solto que vem no pedido.
3. Um teste de recusa por objeto sensível. Faturas, documentos, contas: tudo o que tem dono recebe um teste em que o utilizador errado é recusado.

O que significa o OWASP Top 10 quando agentes de IA escrevem o código?

As categorias não mudam quando agentes de código como Claude Code, Cursor, GitHub Copilot ou OpenAI Codex escrevem o código, mas o volume e a velocidade mudam. Uma equipa que entrega mais alterações por semana precisa dos scanners em cada alteração, e de uma revisão dos controlos de acesso em cada endpoint novo, porque um agente escreve uma rota que funciona com a mesma facilidade com que salta um controlo de dono que nunca lhe foi descrito.

Os mesmos agentes também podem fazer o trabalho defensivo. Um agente que lê o código pode mapear cada endpoint, ver que perfis chegam a cada um, escrever o teste de recusa, corrê-lo e mostrar se falha. É a parte do OWASP Top 10 que os scanners deixam em cima da mesa, e um agente de código consegue fazê-la ao ritmo a que escreve código. O nosso guia de segurança dos agentes de código com IA cobre o outro lado: o que o próprio agente pode executar.

Onde entra a CybeDefend?

O CybeDefend Open Source chega em breve e cobre as duas metades deste artigo. Um comando no teu agente de código, /cybedefend, lança uma auditoria completa em duas camadas. Primeiro os scanners AppSec, open source, entre eles Opengrep, Trivy, Gitleaks e zizmor, para código, dependências, segredos, infraestrutura como código, CI/CD e contentores: os riscos com padrão da tabela acima. Fica com os que quiseres e acrescenta os teus.

Depois, o scanner de IA, corrido pelo teu agente de código. Os scanners procuram padrões. O scanner de IA lê o que o teu código deveria fazer e encontra onde parte, na lógica de negócio, nas permissões de acesso e nas falhas que só aparecem quando o código corre: as linhas A01, A06 e A07. Prova cada falha com um exploit escrito como teste na tua própria suite, como o de cima. Sem modelo extra e sem chave de API: a IA é o agente de código que já usas.

Por baixo das duas camadas está toda a nossa plataforma, um ASPM agêntico. Guarda cada finding numa única fila, e os seus relatórios de segurança associam os findings ao OWASP Top 10 e ao CWE Top 25. Para correr a auditoria sobre o teu próprio código assim que abrir, inscreve-te na lista de espera do CybeDefend Open Source.

Perguntas frequentes

O que há de novo no OWASP Top 10 2025?

Duas categorias novas: Software Supply Chain Failures em A03, que alarga a antiga Vulnerable and Outdated Components aos sistemas de build e à CI/CD, e Mishandling of Exceptional Conditions em A10. A SSRF passa para Broken Access Control e Security Misconfiguration sobe do quinto para o segundo lugar.

Qual é o risco número um do OWASP Top 10 2025?

Broken Access Control, o controlo de acesso falhado, tal como em 2021. Agrupa 40 fraquezas, do path traversal e do CSRF à autorização em falta e aos IDOR, e desde 2025 inclui também a SSRF.

A SSRF ainda faz parte do OWASP Top 10?

Sim, dentro de A01 Broken Access Control. Em 2021 a SSRF tinha categoria própria, a A10; a edição de 2025 integrou-a no controlo de acesso.

Uma ferramenta SAST chega para cobrir o OWASP Top 10?

Não. Uma ferramenta SAST cobre bem Injection e Cryptographic Failures, e parte de várias outras categorias. Os riscos de dependências e da pipeline precisam de uma ferramenta SCA e de um scanner de CI/CD, e o controlo de acesso e o design precisam de testes e da revisão de alguém que conheça as regras da aplicação.

De quanto em quanto tempo é atualizado o OWASP Top 10?

Não há calendário fixo. A edição de 2025 é a oitava, quatro anos depois da de 2021.

A CybeDefend é open source?

A sua edição open source, o CybeDefend Open Source, chega em breve: toda a nossa plataforma, um ASPM agêntico, gratuita para correr nos teus próprios servidores. O comando /cybedefend encadeia os scanners AppSec open source e um scanner de IA corrido pelo teu agente de código, e guarda cada finding numa única fila. Inscreve-te na lista de espera do CybeDefend Open Source.