A OWASP publicou a nova edição do Top 10, a lista de referência mundial para riscos de segurança em aplicações web. A OWASP Top 10:2025 foi apresentada a 6 de novembro de 2025 na conferência Global AppSec DC e já está disponível como versão final no site oficial da fundação, substituindo a edição de 2021 que dominou a área durante quatro anos. Duas categorias novas entram na lista, uma desaparece como entrada autónoma e a ordenação muda de forma significativa logo nos dois primeiros lugares.
Este artigo compara ponto por ponto a OWASP Top 10:2021 com a OWASP Top 10:2025, junta dados de três relatórios distintos da indústria (HackerOne, Verizon e Positive Technologies) e explica, com casos reais como a Capital One e a SolarWinds, o que cada categoria significa na prática. No final há um guia de migração passo a passo e um veredito claro sobre quando vale a pena atualizar o teu programa de segurança de aplicações.
Se trabalhas com programação, gestão de produto ou conformidade regulatória, é provável que já tenhas visto a sigla “OWASP Top 10” citada num relatório de auditoria, numa formação obrigatória de secure coding ou num requisito de contrato com um cliente empresarial. A pergunta que este artigo responde é direta: o que exatamente mudou, quais os números que sustentam essa mudança e o que precisas de fazer, se é que precisas de fazer alguma coisa, antes do fim do ano.
O que mudou entre a OWASP Top 10:2021 e a 2025
A OWASP Top 10 nasceu em 2003 e é atualizada sempre que a fundação recolhe dados suficientes de bases de vulnerabilidades, testes de penetração e contribuições da indústria para justificar uma nova ordenação. A edição de 2021 ficou em vigor durante quatro anos, o intervalo mais longo da história do projeto. Segundo a própria página oficial da OWASP Top 10:2025, a recolha de dados decorreu entre junho e dezembro, a análise e o rascunho ficaram prontos no início de 2025 e a versão final chegou junto com o anúncio em novembro.
Vale lembrar que a Top 10 nunca pretendeu ser uma lista exaustiva de vulnerabilidades. É antes um instrumento de priorização, pensado para ajudar equipas com recursos limitados a decidir onde investir primeiro tempo de auditoria e correção. Por isso a ordem das categorias importa tanto quanto os nomes: uma categoria subir dois ou três lugares muda diretamente o argumento que uma equipa de segurança usa para justificar orçamento junto da liderança da empresa.
A mudança mais visível não está numa categoria nova, mas na reorganização do topo da tabela. O Controlo de Acesso Quebrado mantém-se no primeiro lugar, tal como em 2021, mas a Configuração Incorreta de Segurança salta do quinto para o segundo posto. Isso reflete um padrão que qualquer equipa de infraestrutura cloud reconhece: erros de configuração em contentores, buckets de armazenamento e permissões IAM tornaram-se mais comuns do que falhas clássicas de criptografia, que caem para quarto lugar. A lista de 2025 também formaliza algo que já acontecia na prática há anos, o facto de muitos incidentes graves nascerem de dependências de terceiros e não de código escrito internamente.
Duas categorias somem do formato antigo: os Componentes Vulneráveis e Desatualizados (A06:2021) deixam de existir como tal e dão lugar a uma definição mais ampla, e o SSRF (A10:2021) deixa de ser uma entrada isolada. Em troca, entram as Falhas na Cadeia de Fornecimento de Software e o Tratamento Inadequado de Condições Excecionais, ambas detalhadas mais à frente neste artigo.
Tabela comparativa: OWASP Top 10:2021 vs 2025
A tabela seguinte junta as duas edições lado a lado, categoria por categoria, com a posição de cada risco nos dois anos. É a referência mais rápida para quem quer perceber de imediato o que subiu, o que desceu e o que é completamente novo.
| Posição | OWASP Top 10:2021 | OWASP Top 10:2025 | Mudança |
|---|---|---|---|
| 1 | Controlo de Acesso Quebrado | Controlo de Acesso Quebrado (agora inclui SSRF) | Mantém-se, absorve o SSRF |
| 2 | Falhas Criptográficas | Configuração Incorreta de Segurança | Subiu do 5º lugar |
| 3 | Injeção | Falhas na Cadeia de Fornecimento de Software | Categoria nova, expande o A06:2021 |
| 4 | Design Inseguro | Falhas Criptográficas | Desceu do 2º lugar |
| 5 | Configuração Incorreta de Segurança | Injeção | Desceu do 3º lugar |
| 6 | Componentes Vulneráveis e Desatualizados | Design Inseguro | Desceu do 4º lugar |
| 7 | Falhas de Identificação e Autenticação | Falhas de Autenticação | Mantém posição, nome simplificado |
| 8 | Falhas de Integridade de Software e Dados | Falhas de Integridade de Software ou Dados | Mantém posição |
| 9 | Falhas de Registo e Monitorização de Segurança | Falhas de Registo e Alerta de Segurança | Mantém posição, foco em alertas |
| 10 | SSRF (Server-Side Request Forgery) | Tratamento Inadequado de Condições Excecionais | SSRF sai, categoria totalmente nova entra |
O resultado líquido: duas categorias novas (Cadeia de Fornecimento e Condições Excecionais), uma fusão (SSRF dentro de Controlo de Acesso) e uma reordenação que empurra a Configuração Incorreta de Segurança para o topo da lista. Um artigo de análise da bug-bounties.as93.net, focado em caçadores de bugs, resume a mudança como um afastamento de vulnerabilidades de código isoladas em direção a falhas sistémicas de arquitetura e cadeia de fornecimento.
As duas categorias completamente novas, explicadas
A03:2025: Falhas na Cadeia de Fornecimento de Software
Esta categoria não nasce do zero. Ela expande e substitui os antigos “Componentes Vulneráveis e Desatualizados” (A06:2021), mas alarga o âmbito muito para além de “atualiza a tua dependência desatualizada”. Cobre agora pipelines de CI/CD comprometidos, registos de pacotes envenenados, scripts de build maliciosos e dependências transitivas que ninguém na equipa auditou. A criação desta categoria surge depois de uma sucessão de incidentes que mostraram como um único pacote comprometido pode afetar milhares de organizações em simultâneo.
O exemplo mais recente e ainda a decorrer quando este artigo foi escrito envolve o compromisso de pacotes populares do ecossistema TanStack, em agosto de 2026, que obrigou equipas a auditar árvores de dependências inteiras e a rodar credenciais em massa, segundo a análise da Cloud Security Alliance. É precisamente este tipo de incidente, com centenas de pacotes derivados afetados de uma só vez, que justifica dar à cadeia de fornecimento uma categoria própria em vez de a deixar diluída dentro de “componentes desatualizados”.
A10:2025: Tratamento Inadequado de Condições Excecionais
Esta é a categoria genuinamente nova, sem equivalente direto em 2021. Cobre falhas de tratamento de erros, timeouts mal configurados, esgotamento de recursos e respostas de erro que revelam informação sensível ou deixam o sistema num estado inconsistente. Não é um conceito exótico. Qualquer programador já viu uma exceção não tratada expor um stack trace completo ao utilizador, ou um timeout mal definido deixar uma transação a meio, com dados inconsistentes na base de dados.
A OWASP decidiu isolar este padrão porque ele aparece repetidamente em auditorias e relatórios de incidentes, mas raramente é tratado como problema de segurança propriamente dito. Costuma ser classificado como “bug de qualidade” e empurrado para o fundo da lista de prioridades. Ao dar-lhe uma categoria própria no Top 10:2025, a fundação obriga as equipas de AppSec a tratá-lo com o mesmo peso de uma injeção de SQL.
Porque a configuração incorreta de segurança subiu ao 2º lugar
Em 2021, a Configuração Incorreta de Segurança ocupava o quinto lugar. Em 2025 salta três posições e fica logo atrás do Controlo de Acesso Quebrado. A explicação está na mudança de onde o código corre. Há quatro anos, boa parte das aplicações ainda vivia em servidores geridos diretamente pela equipa de infraestrutura, com configurações relativamente estáveis. Hoje, a mesma aplicação pode passar por dezenas de camadas de configuração: cluster Kubernetes, políticas IAM da cloud, regras de rede, variáveis de ambiente em contentores e definições de um fornecedor SaaS terceiro.
Cada camada nova é uma oportunidade de erro. Um bucket de armazenamento deixado como público, uma política IAM demasiado permissiva ou uma consola de administração exposta à internet sem autenticação são exemplos clássicos, e continuam a aparecer em auditorias com uma frequência que já não se explica como acidente isolado. O próprio caso Capital One, discutido mais à frente, começou exatamente com uma firewall de aplicação web mal configurada.
Para equipas técnicas, a lição prática é simples: ferramentas de deteção de configuração incorreta, sejam scanners de infraestrutura como código ou verificações contínuas de postura cloud, deixam de ser um extra e passam a ser tão centrais como um scanner SAST tradicional.
O SSRF não desapareceu, foi absorvido pelo controlo de acesso
Uma das perguntas mais comuns sobre a nova lista é se o Server-Side Request Forgery deixou de ser um risco relevante. Não deixou. O que aconteceu foi uma reclassificação: em vez de ser a décima categoria isolada, o SSRF passa a estar dentro do Controlo de Acesso Quebrado (A01:2025). A lógica por trás desta fusão é que, na prática, um ataque de SSRF bem-sucedido é quase sempre uma forma de acesso não autorizado a um recurso interno, disfarçado de pedido legítimo feito pelo próprio servidor.
Em 2021, a OWASP tinha justificado a criação de uma categoria isolada para o SSRF citando precisamente o caso Capital One como motivo. Quatro anos depois, com mais dados acumulados de testes de penetração e programas de bug bounty, a fundação concluiu que tratar o SSRF como categoria própria criava sobreposição desnecessária com o Controlo de Acesso Quebrado, já que os dois problemas partilham a mesma causa raiz: falta de verificação sobre que recursos um utilizador ou processo pode alcançar.
Isto tem uma consequência prática direta para quem escreve código: proteger contra SSRF continua obrigatório, só que agora entra na mesma checklist de validação de permissões em vez de ter uma checklist separada. Um exemplo simples de mitigação em Node.js é restringir explicitamente que domínios e IPs uma função pode contactar antes de fazer o pedido em nome do servidor:
const allowedHosts = new Set(['api.parceiro-confiavel.pt']);
function validarDestino(url) {
const alvo = new URL(url);
if (!allowedHosts.has(alvo.hostname)) {
throw new Error('Destino não autorizado para pedido do servidor');
}
if (['127.0.0.1', 'localhost', '169.254.169.254'].includes(alvo.hostname)) {
throw new Error('Bloqueado: endereço interno ou de metadados da cloud');
}
return alvo;
}O bloqueio explícito do endereço 169.254.169.254, o serviço de metadados usado pela AWS e por outras clouds, não é um detalhe menor. Foi precisamente esse endereço que a Capital One não protegeu em 2019, e o resultado foi o roubo de dados de mais de 100 milhões de clientes.
OWASP API Security Top 10: continua na edição de 2023
Vale a pena esclarecer uma confusão comum. A OWASP mantém dois documentos distintos: a Top 10 geral para aplicações web, agora na edição de 2025, e a OWASP API Security Top 10, focada especificamente em riscos de APIs. Apesar de pesquisas frequentes por uma “API Top 10 2025”, a fundação não publicou uma atualização. A edição oficial de 2023 continua a ser a referência válida em 2026, e vários guias especializados confirmam isso explicitamente para evitar confusão entre equipas.
A lista de 2023, a segunda edição do documento, mantém a Autorização Quebrada ao Nível do Objeto (BOLA) no primeiro lugar, uma posição que já ocupava desde 2019. As dez categorias são:
- API1:2023: Autorização Quebrada ao Nível do Objeto (BOLA)
- API2:2023: Autenticação Quebrada
- API3:2023: Autorização Quebrada ao Nível da Propriedade do Objeto
- API4:2023: Consumo Irrestrito de Recursos
- API5:2023: Autorização Quebrada ao Nível da Função
- API6:2023: Acesso Irrestrito a Fluxos de Negócio Sensíveis
- API7:2023: Server-Side Request Forgery
- API8:2023: Configuração Incorreta de Segurança
- API9:2023: Gestão Inadequada de Inventário
- API10:2023: Consumo Inseguro de APIs
Para equipas que constroem APIs, a recomendação prática dos guias mais recentes é usar as duas listas em conjunto: a Top 10:2025 como referência de arquitetura geral e a API Top 10:2023 como checklist específica para cada endpoint exposto. Nenhuma substitui a outra.
Repara na semelhança entre as duas listas apesar dos anos de distância entre edições. A Autorização Quebrada ao Nível do Objeto, no topo da lista de APIs desde 2019, é essencialmente a mesma família de problema que o Controlo de Acesso Quebrado no topo da lista geral. Isto não é coincidência. Mostra que o problema central da segurança de aplicações modernas continua a ser o mesmo há anos: verificar corretamente quem pode aceder a que recurso, e não tanto impedir que código malicioso seja executado.
Os números que comprovam a mudança de prioridades
A reordenação da OWASP não surge do nada. Três relatórios independentes da indústria, publicados entre 2025 e 2026, mostram o mesmo padrão: falhas de autorização e configuração dominam, enquanto vulnerabilidades clássicas como o XSS perdem peso relativo.
| Fonte | Métrica | Valor reportado |
|---|---|---|
| HackerOne, Hacker-Powered Security Report (9ª edição) | Recompensas pagas por Controlo de Acesso Impróprio | 8,8 milhões de dólares em 8.787 relatórios válidos, +18% em volume face ao ano anterior |
| HackerOne, Hacker-Powered Security Report (9ª edição) | Recompensas pagas por Cross-Site Scripting | 8,4 milhões de dólares em 13.197 relatórios, -14% em volume face ao ano anterior |
| HackerOne, Hacker-Powered Security Report (9ª edição) | Crescimento de vulnerabilidades de prompt injection em IA | +540% ano a ano |
| Verizon, Data Breach Investigations Report 2026 | Violações causadas por intrusão de sistema | 61% dos casos analisados |
| Verizon, Data Breach Investigations Report 2026 | Violações causadas por engenharia social | 17% dos casos analisados |
| Verizon, Data Breach Investigations Report 2026 | Violações por ataques básicos a aplicações web | 10% dos casos analisados |
| Positive Technologies, Standoff Bug Bounty (revisão de 2025) | Controlo de Acesso Quebrado entre vulnerabilidades críticas e altas | 58% do total encontrado na plataforma em 2025 |
Repara no fio condutor: três fontes diferentes, com metodologias diferentes (recompensas de bug bounty, investigação forense de violações reais e testes ofensivos em ambiente controlado), chegam à mesma conclusão. Falhas de autorização e acesso lideram de forma isolada. O relatório completo da HackerOne associa esta tendência ao crescimento de sistemas com mais superfícies de API e mais integrações automatizadas, exatamente o tipo de ambiente onde um simples erro de permissão se transforma em acesso total.
O relatório da Verizon reforça o argumento a partir de outro ângulo. Ao comparar 2024, 2025 e 2026, a percentagem de violações atribuídas a “intrusão de sistema” sobe de 36% para 53% e depois para 61%, um crescimento consistente que coincide diretamente com a subida da Configuração Incorreta de Segurança no Top 10 da OWASP.
6 casos reais que explicam cada categoria de risco
Números abstratos ajudam pouco sem exemplos concretos. Estes seis incidentes, todos amplamente documentados, mostram como cada categoria da OWASP Top 10 se traduz num incidente real. Nenhum deles é hipotético ou reconstruído para ilustrar um ponto teórico, todos afetaram clientes reais, geraram custos concretos e mudaram práticas de segurança em toda a indústria depois de serem tornados públicos.
- Capital One (2019): Configuração Incorreta e SSRF. Uma firewall de aplicação web mal configurada na AWS permitiu que um atacante explorasse SSRF para alcançar o serviço de metadados da instância e roubar credenciais temporárias, expondo dados de mais de 106 milhões de clientes, segundo a análise da Cloudskope.
- SolarWinds (2020): Falhas na Cadeia de Fornecimento. Atacantes comprometeram o sistema de build da SolarWinds e inseriram a backdoor SUNBURST em atualizações do software Orion. Cerca de 18 mil organizações chegaram a instalar a atualização maliciosa, de acordo com a ReversingLabs.
- Codecov (2021): Falhas de Integridade de Software. Um script de upload usado por milhares de pipelines de CI foi alterado por atacantes, permitindo a exfiltração de segredos e tokens de ambientes de desenvolvimento durante meses antes de ser detetado.
- Okta (outubro de 2023): Cadeia de Fornecimento via Fornecedor de Suporte. Atacantes obtiveram acesso ao sistema de gestão de casos de suporte da Okta e, através dele, a dados de clientes, um lembrete de que a cadeia de fornecimento inclui também fornecedores de software de apoio, não só bibliotecas de código, segundo a análise da Cisco Outshift.
- 3CX (2023): Cadeia de Fornecimento Dupla. Um caso raro em que uma empresa foi comprometida através de uma dependência que, por sua vez, já tinha sido vítima de outro ataque à cadeia de fornecimento, afetando cerca de 600 mil clientes do software de comunicações da 3CX, conforme documentado pela ShieldedStack.
- Pacotes TanStack (agosto de 2026): Cadeia de Fornecimento em Curso. Um conjunto de pacotes populares do ecossistema JavaScript foi comprometido, afetando centenas de dependências derivadas e obrigando equipas a rodar credenciais em massa, um exemplo direto e recente da categoria A03:2025.
Nota-se um padrão nestes seis casos: quatro em seis envolvem, de alguma forma, a cadeia de fornecimento de software. Isso confirma, com exemplos concretos, a decisão da OWASP de lhe dar destaque próprio na edição de 2025 em vez de a deixar escondida dentro de “componentes desatualizados”. Repara também que três dos seis casos, Okta, 3CX e TanStack, aconteceram depois de 2022, o que sugere que a frequência deste tipo de incidente está a aumentar e não a diminuir, apesar dos investimentos crescentes das empresas em segurança de aplicações ao longo dos últimos anos.
Quanto custa cobrir o novo Top 10 com ferramentas
Adotar a OWASP Top 10:2025 não obriga a comprar ferramentas novas, mas obriga a rever se as ferramentas atuais cobrem as categorias que mudaram de peso, sobretudo a cadeia de fornecimento e a configuração de infraestrutura. A tabela seguinte junta preços públicos de ferramentas de SAST, DAST e SCA usadas para cobrir diferentes categorias da lista.
| Ferramenta | Tipo | Preço de entrada | Cobre principalmente |
|---|---|---|---|
| OWASP ZAP | DAST | Grátis (open source) | Injeção, Configuração Incorreta |
| Burp Suite Community | DAST | Grátis | Injeção, Controlo de Acesso |
| Burp Suite Professional | DAST | 499 USD por utilizador/ano | Injeção, Controlo de Acesso, SSRF |
| SonarQube Community | SAST | Grátis (open source) | Injeção, Design Inseguro |
| Snyk Free | SCA | 0 USD/mês | Cadeia de Fornecimento |
| Snyk Team | SCA | 25 USD/mês por developer | Cadeia de Fornecimento |
| Veracode | SAST + DAST | A partir de cerca de 15.000 USD/ano | Múltiplas categorias, cobertura empresarial |
| Checkmarx One | SAST | Sob consulta (sem lista pública) | Injeção, Cadeia de Fornecimento |
O preço da licença Burp Suite Professional subiu de 449 para 499 dólares por utilizador em janeiro de 2026, e o plano gratuito e de código aberto da Snyk continua a ser suficiente para equipas pequenas cobrirem a nova categoria de cadeia de fornecimento sem custo inicial. Já Veracode e Checkmarx seguem o modelo tradicional de vendas empresariais, sem preço de lista público, o que dificulta a comparação direta mas costuma incluir suporte dedicado e cobertura mais ampla de linguagens.
Para uma comparação mais aprofundada entre as três principais plataformas de análise estática, o artigo SonarQube vs Checkmarx vs Veracode detalha o número de regras cobertas por cada motor. Quem já usa Burp Suite ou pondera trocar por uma alternativa gratuita pode consultar também a comparação entre Burp Suite e OWASP ZAP.
Vale sublinhar que nenhuma destas ferramentas resolve sozinha a nova categoria de Falhas na Cadeia de Fornecimento. Um scanner SAST analisa o código que a tua equipa escreve, não as dependências que instalas de registos públicos como o npm ou o PyPI. Para cobrir A03:2025 de forma completa, a maioria das equipas acaba por combinar duas ou três categorias de ferramentas em simultâneo: um SCA para dependências diretas e transitivas, um scanner de segredos para evitar chaves de API expostas em repositórios, e cada vez mais também uma verificação de integridade de pipelines de CI/CD, uma área onde a oferta de ferramentas ainda é mais recente e menos padronizada do que em SAST ou DAST.
Guia de migração: do Top 10:2021 para o Top 10:2025 em 6 passos
Migrar um programa de segurança de aplicações de uma edição para outra não é um interruptor que se liga. É um processo gradual que costuma demorar um a dois trimestres numa empresa de média dimensão. Segue-se um guia prático em seis passos.
- Mapeia as políticas atuais para a nova numeração. Se o teu programa de conformidade cita “A06:2021”, atualiza a referência para “A03:2025” quando o assunto for cadeia de fornecimento, e sinaliza onde o SSRF (antigo A10) passa a estar dentro do A01.
- Audita a cobertura de ferramentas para as duas categorias novas. Confirma se o teu scanner SCA cobre pipelines de CI/CD e não só dependências declaradas em package.json ou requirements.txt.
- Revê o tratamento de exceções no código crítico. Procura por blocos try/catch vazios, mensagens de erro que expõem detalhes internos e timeouts sem limite definido, o núcleo do novo A10:2025.
- Reordena as prioridades de correção de vulnerabilidades pendentes. Se tens um backlog de findings antigos classificados por A05:2021 (Configuração), sobe-os na fila, já que a categoria agora ocupa o segundo lugar geral.
- Atualiza a formação interna de programadores. Sessões de secure coding baseadas na lista de 2021 precisam de referir explicitamente as mudanças, sobretudo a fusão do SSRF, para evitar confusão em code reviews.
- Mantém a API Security Top 10:2023 em paralelo. Não a substituas nem a ignores. Usa-a como checklist complementar sempre que a auditoria envolver endpoints de API e não apenas páginas web tradicionais.
Equipas que já usam ferramentas automatizadas de deteção de dependências, como as descritas na comparação entre Snyk, Dependabot e Socket, têm uma vantagem clara neste processo, porque grande parte do trabalho de mapear a nova categoria de cadeia de fornecimento já está automatizado.
Quem deve adotar já a OWASP Top 10:2025
Nem todas as equipas têm a mesma urgência para migrar. Estes são os perfis onde a atualização traz benefício imediato e mensurável.
- Equipas com infraestrutura cloud extensa e múltiplos clusters Kubernetes, onde a Configuração Incorreta de Segurança já é, na prática, a causa mais comum de incidentes internos.
- Organizações com muitas dependências open source e pipelines de CI/CD complexos, que ganham ao formalizar a cadeia de fornecimento como categoria de risco própria em vez de a tratar como item secundário de manutenção.
- Empresas sujeitas ao regime de cibersegurança NIS2 em Portugal, que precisam de demonstrar processos de gestão de risco atualizados perante auditorias, um contexto onde citar a lista mais recente da OWASP reforça a credibilidade do relatório.
- Equipas que constroem APIs públicas ou para parceiros, que devem cruzar a Top 10:2025 com a API Security Top 10:2023 em vez de escolher apenas uma.
- Startups em fase inicial com equipas de segurança pequenas, que podem usar a nova ordenação para priorizar esforço limitado: primeiro Controlo de Acesso, depois Configuração, só depois o resto.
- Consultoras e auditores externos, que precisam de atualizar templates de relatório e checklists de pentest para refletir a numeração de 2025 antes do próximo ciclo de auditorias a clientes.
Impacto para empresas em Portugal e na União Europeia
Em Portugal, a atualização da OWASP chega numa altura em que o regime jurídico da cibersegurança já obriga milhares de empresas a documentar formalmente a gestão de risco de aplicações. O diploma que transpõe a diretiva NIS2 para o direito nacional abrange cerca de nove mil entidades, entre operadores de serviços essenciais e fornecedores digitais, com coimas que podem chegar aos dez milhões de euros em caso de incumprimento grave. Uma equipa de conformidade que cite a OWASP Top 10:2021 num relatório de auditoria entregue em 2026 arrisca-se a uma observação do avaliador a perguntar porque não usou a edição mais recente, mesmo que a diferença prática entre as duas seja pequena para o caso concreto.
O mesmo raciocínio aplica-se ao Cyber Resilience Act da União Europeia, que impõe requisitos de segurança a produtos com componentes digitais e cujo prazo de adaptação obriga fabricantes de software a documentar o processo de gestão de vulnerabilidades ao longo do ciclo de vida do produto. Nesse contexto, a nova categoria de Falhas na Cadeia de Fornecimento de Software (A03:2025) tem uma relevância direta, porque o regulamento europeu também exige rastreabilidade de componentes de terceiros integrados no software, o mesmo problema que a OWASP decidiu isolar como categoria própria.
Para equipas portuguesas de dimensão média, sem departamento de AppSec dedicado, a recomendação prática é simples: não é preciso substituir ferramentas nem contratar consultoria externa só para “estar em dia” com a numeração de 2025. Basta atualizar a referência nos documentos de política de segurança já existentes e garantir que o próximo ciclo de testes de penetração contratado a um fornecedor externo já usa a lista atual como base de referência.
Vantagens e desvantagens do novo framework
Como qualquer mudança de referência usada por milhares de equipas em todo o mundo, a Top 10:2025 tem pontos fortes claros e também compromissos que vale a pena conhecer antes de reescrever documentação interna.
Vantagens
- Reflete melhor a realidade de arquiteturas cloud-native e pipelines automatizados, em vez de assumir servidores estáticos.
- Dá visibilidade própria à cadeia de fornecimento, um risco que crescia há anos sem categoria dedicada.
- Simplifica a lista ao absorver o SSRF dentro do Controlo de Acesso, reduzindo sobreposição entre categorias.
- Baseia-se em dados agregados de vários contribuidores da indústria, recolhidos ao longo de um ano inteiro.
Desvantagens
- Obriga a reescrever documentação, políticas internas e materiais de formação já existentes.
- A fusão do SSRF pode confundir equipas habituadas a tratá-lo como item isolado numa checklist.
- Muitas ferramentas comerciais ainda não atualizaram os seus relatórios e templates para a nova numeração, o que cria um período de transição com referências mistas.
- A falta de uma API Security Top 10 atualizada em paralelo deixa uma lacuna para equipas que trabalham quase exclusivamente com APIs.
Veredito: vale a pena mudar já?
Sim, mas sem pressa desnecessária. A OWASP Top 10:2025 já é a versão final e substitui oficialmente a de 2021, por isso qualquer programa de segurança novo deve nascer já alinhado com ela. Para programas existentes, a migração compensa mais pela reordenação de prioridades do que pela adoção de ferramentas novas: os dados da HackerOne e da Verizon confirmam que Controlo de Acesso e Configuração Incorreta já dominam os incidentes reais, então subir essas categorias no backlog de correções traz retorno imediato, independentemente da numeração usada internamente.
Onde a mudança exige mais trabalho é na cadeia de fornecimento. Se a tua equipa ainda trata dependências desatualizadas como um item de manutenção de rotina, os casos da SolarWinds, do 3CX e dos pacotes TanStack mostram que este risco já merece o mesmo nível de atenção formal que uma falha de injeção clássica. E lembra-te sempre de manter a API Security Top 10:2023 por perto caso a tua aplicação exponha endpoints, porque a OWASP não a substituiu nem tem planos anunciados para o fazer a curto prazo.
Em números concretos: se a tua equipa só consegue dedicar tempo a duas frentes este trimestre, os dados apontam para uma escolha clara. Prioriza controlo de acesso, responsável por 58% das vulnerabilidades críticas e altas encontradas em bug bounty segundo a Positive Technologies, e depois cadeia de fornecimento, a categoria por trás de quatro dos seis incidentes reais descritos neste artigo. Tudo o resto, incluindo a atualização cosmética de documentação e templates, pode esperar pelo próximo ciclo de planeamento sem risco adicional.
Perguntas frequentes
O que é a OWASP Top 10:2025?
É a edição mais recente da lista de referência da OWASP para os dez riscos de segurança mais críticos em aplicações web, publicada como versão final a 6 de novembro de 2025 e substituindo a edição de 2021.
Quais são as duas categorias novas na OWASP Top 10:2025?
São as Falhas na Cadeia de Fornecimento de Software (A03:2025), que expande os antigos componentes desatualizados, e o Tratamento Inadequado de Condições Excecionais (A10:2025), uma categoria sem equivalente direto em 2021. Juntas, refletem uma preocupação crescente com riscos que nascem fora do código escrito diretamente pela equipa, seja em dependências de terceiros ou em falhas de robustez do próprio sistema.
O SSRF deixou de ser um risco reconhecido pela OWASP?
Não. O SSRF deixou de ser uma categoria isolada e passou a estar incluído dentro do Controlo de Acesso Quebrado (A01:2025), porque a maioria dos ataques de SSRF resulta, na prática, em acesso não autorizado a recursos internos.
Existe uma OWASP API Security Top 10 de 2025 ou 2026?
Não. A edição de 2023 continua a ser a versão oficial e mais recente em 2026. A OWASP não anunciou uma atualização específica para APIs, apesar de pesquisas frequentes por uma versão mais recente. Equipas que trabalham com APIs devem continuar a usar a lista de 2023 lado a lado com a Top 10:2025, em vez de esperar por uma revisão que ainda não tem data anunciada.
A OWASP Top 10:2021 ainda pode ser usada?
Pode ser usada como referência histórica, mas deixou de ser a edição oficial. Programas de conformidade e auditorias novas devem citar a Top 10:2025 a partir de agora.
Quanto custa implementar ferramentas para cobrir o novo Top 10?
Depende da dimensão da equipa. É possível cobrir boa parte das categorias com ferramentas gratuitas e open source, como OWASP ZAP, Burp Suite Community e SonarQube Community. Equipas maiores costumam combinar Snyk (a partir de 25 dólares por developer/mês) com Burp Suite Professional (499 dólares por utilizador/ano) ou soluções empresariais como Veracode, com contratos a partir de cerca de 15 mil dólares por ano.
Porque é que a Configuração Incorreta de Segurança subiu tanto na lista?
Porque a complexidade das arquiteturas cloud, com múltiplas camadas de permissões, contentores e integrações automatizadas, multiplicou o número de pontos onde um erro de configuração pode acontecer. Os dados da Verizon mostram que as violações atribuídas a intrusão de sistema, categoria que inclui muitos casos de configuração incorreta, subiram de 36% em 2024 para 61% em 2026.
Preciso de reescrever toda a documentação de segurança da empresa de imediato?
Não de um dia para o outro. O recomendado é seguir o guia de migração em seis passos deste artigo, começando por mapear a numeração antiga para a nova e só depois atualizar formação, templates de auditoria e políticas internas.
