O perímetro tradicional de segurança se dissolveu. Não somente porque os atacantes ficaram “mais inteligentes”, mas porque o software mudou de forma. Aplicações modernas não são somente escritas; elas são montadas a partir de APIs, serviços de terceiros, dependências e componentes orientados a eventos. O OWASP Top 10:2025 reforça o que arquitetos já sentem em produção: os maiores riscos não são erros de digitação e escapes faltando — são falhas sistêmicas que surgem de escolhas de design, cadeias de suprimentos (supply chain) e complexidade operacional.
É por isso que a segurança não pode mais ficar só na origem. Para atender à realidade de 2026, as equipes precisam de uma camada programável capaz de aplicar políticas, validar a intenção e absorver incertezas antes que virem um incidente.
A Azion foi construída para essa mudança: uma plataforma web que permite às empresas criar, proteger e escalar aplicações modernas em uma infraestrutura global totalmente gerenciada — combinando computação distribuída, capacidades serverless e observabilidade em tempo real (Real-Time Metrics & Events) como uma abordagem unificada, e não como ferramentas desconectadas.
O OWASP Top 10:2025 reúne as dez principais categorias de risco para aplicações web modernas. Em relação à edição de 2021, a nova versão amplia o foco em riscos arquiteturais, supply chain, design inseguro e tratamento de condições excepcionais — refletindo a crescente complexidade das aplicações distribuídas. WAFs baseados em regras estáticas não cobrem essa superfície. Uma arquitetura de segurança distribuída é o que mitiga ameaças modernas de forma consistente.
Quais são as principais mudanças do OWASP Top 10:2025?
A edição de 2025 não é uma atualização incremental. É uma revisão conceitual: o OWASP Top 10:2025 reconhece que os maiores riscos para aplicações modernas não são erros de digitação ou escapes faltando — são falhas sistêmicas que surgem de escolhas de design, cadeias de suprimentos e complexidade operacional.
As três mudanças mais relevantes em relação ao OWASP Top 10:2021:
- SSRF incorporado ao A01 — Server-Side Request Forgery, que na versão 2021 era a categoria A10 isolada, foi consolidado em Broken Access Control. A consolidação reconhece que SSRF é fundamentalmente uma falha de controle de acesso: a aplicação faz requisições para destinos que não deveria acessar.
- Supply Chain como categoria explícita no A03 — Antes restrita a “componentes com vulnerabilidades conhecidas”, a categoria 2025 cobre o ciclo de vida completo do software: dependências, pipelines de build e artefatos sem assinatura.
- A10 é uma categoria inédita — Mishandling of Exceptional Conditions entra pela primeira vez, reconhecendo que tratamento inadequado de erros não é só um problema de UX — é um vetor de exaustão de recursos explorado ativamente por atacantes.
O que isso significa na prática: a segurança não pode mais ficar só na origem. As equipes precisam de uma arquitetura de segurança distribuída capaz de aplicar políticas, validar intenção e absorver ameaças antes que virem incidente — o que inclui computação serverless para lógica de autorização no perímetro, WAF com análise heurística multicamada e observabilidade em tempo real.
Uma arquitetura de segurança distribuída aplica políticas antes que a requisição alcance a aplicação de origem, usando regras distribuídas, computação serverless e observabilidade em tempo real.
A01: Broken Access Control — aplicar política antes da requisição chegar à origem
Broken Access Control, agora consolidado para incluir SSRF, continua sendo a vulnerabilidade mais prevalente em sistemas reais — especialmente quando a lógica de autorização está espalhada por múltiplos serviços e endpoints. Defesas tradicionais bloqueiam padrões estruturais óbvios, como directory traversal (../../etc/passwd), mas não detectam falhas lógicas: se este usuário deveria acessar aquele objeto.
Uma arquitetura distribuída muda o modelo: é possível validar contexto de identidade, normalizar requisições e aplicar regras determinísticas para rotas sensíveis antes de qualquer tráfego chegar à origem.
O WAF da Azion usa as famílias de ameaças Directory Traversal e Unwanted Access para bloquear forced browsing e violações de sistema de arquivos de forma determinística. Para riscos lógicos como Insecure Direct Object References (IDOR), as Azion Functions oferecem interceptação stateless no perímetro — decodificando JWTs e verificando se o claim sub corresponde ao user_id no caminho da requisição, sem exigir alterações no backend.
Se o controle de acesso ainda é “na melhor tentativa” dentro de cada microsserviço, não é controle de acesso — é esperança.
A02: Security Misconfiguration — controles compensatórios para config drift inevitável
Velocidade cloud-native cria config drift. O risco não é descuido — é que a complexidade torna “configuração perfeita” inviável em escala. Um header incorreto, uma resposta de erro detalhada demais ou um caminho de admin exposto vira um primitivo de ataque.
A resposta prática é o controle compensatório: aplicar postura de segurança no perímetro para que serviços internos possam evoluir sem reintroduzir estados ruins já conhecidos.
O Azion Firewall atua como um invólucro de segurança sobre a infraestrutura interna. Com o Rules Engine, é possível injetar headers obrigatórios como HSTS e CSP em todas as respostas — independente do estado de cada serviço de origem. A plataforma intercepta códigos 4xx e 5xx e substitui stack traces verbosos (CWE-209) por HTML sanitizado e customizado, impedindo que atacantes façam reconhecimento da pilha tecnológica via respostas de erro.
A03: Supply Chain — virtual patching quando corrigir rápido não é realista
Risco de supply chain não é teórico. Uma dependência vulnerável pode virar incidente global antes que o processo de gestão de mudanças marque uma reunião. Em empresas com centenas de serviços, a remediação manual de zero-days pode levar semanas — como demonstrado pelo Log4Shell (CVE-2021-44228) e pelo exploit do Apache HTTP Server (CVE-2021-41773).
O OWASP Top 10:2025 update para essa categoria deixa claro: o problema não é só ter componentes desatualizados. É a incapacidade de responder rápido o suficiente quando uma vulnerabilidade crítica é publicada.
Virtual patching é a resposta: aplicar regras de bloqueio no perímetro enquanto o código subjacente ainda não foi corrigido. O WAF da Azion inspeciona requisições de entrada em busca de strings JNDI, expressões OGNL e outros padrões associados a exploits conhecidos. Atualizações de regras são aplicadas globalmente sem janela de manutenção ou deploy. Isso transforma “Shift Left” em “Shield Right”: proteger em produção enquanto a correção acontece no código.
A04: Cryptographic Failures — TLS não é problema da origem, é do perímetro
Falhas criptográficas raramente acontecem porque equipes não conhecem TLS. Acontecem porque origens legadas, configurações inconsistentes e arquiteturas com múltiplos serviços criam postura de segurança desigual. O ponto de aplicação precisa ser centralizado.
A Azion termina TLS na borda como reverse proxy seguro, garantindo conformidade criptográfica independente do estado do servidor de origem. Administradores configuram versão mínima de TLS (1.2 ou 1.3) e desabilitam cifras fracas como RC4 e DES em um único ponto que cobre toda a superfície de entrada.
O recurso de Log Scrubbing mascara PII e números de cartão (CWE-532) antes de logs serem enviados para SIEMs externos — garantindo que sistemas de observabilidade não se tornem uma fonte de exposição de dados em texto claro.
A05: Injection — evasão de payload é o problema real
Injeção ainda funciona porque inputs ainda chegam a interpretadores. O que mudou é a forma dos payloads: mais JSON, encoding em múltiplas camadas, parsing distribuído. Defesas baseadas apenas em regex desmoronam com evasão ou geram falsos positivos com custo operacional alto.
O WAF da Azion usa libinjection (Rule IDs 17 e 18) para tokenizar a entrada e entender a lógica da injeção — reconhecendo tautologias em vez de comparar strings — o que reduz significativamente falsos positivos. A abordagem é complementada por análise heurística em múltiplas camadas:
- Rule 1000: detecção de palavras-chave SQL no body, path e cookies
- Rules 1009 e 1010: identificação de padrões de caracteres especiais indicativos de injeção ((, ), =)
- Rules 13 e 15: validação rigorosa de formatos POST e estruturas JSON para frustrar técnicas de evasão por encoding
Se a defesa contra injeção ainda é comparação de strings, a postura é de 2012 com tráfego de 2026.
A06: Insecure Design — lógica de negócio precisa de defesa como infraestrutura
Insecure Design não é um bug: é quando o sistema permite abuso por projeto — scraping, monopolização de estoque, drenagem de recursos, requisições válidas com intenção maliciosa. Essas lacunas são difíceis de corrigir no código porque o abuso é distribuído, adaptativo e frequentemente indistinguível de tráfego legítimo sem contexto adicional.
O Bot Manager da Azion diferencia usuários legítimos de scripts automatizados via análise comportamental baseada em intenção e fingerprinting de dispositivo. Combinado com rate limiting sensível a contexto — limitando requisições com base em cookies ou headers específicos, não apenas por IP — a plataforma impede que bots explorem lacunas de design sem exigir que a aplicação seja reescrita.
A07: Identification and Authentication Failures — rate limiting por IP não resolve credential stuffing
Credential stuffing funciona não porque atacantes são sofisticados — funciona porque a maioria das defesas é simplista: limites por IP, thresholds fixos e logs isolados. Ataques modernos distribuem tentativas por milhares de IPs e calibram a taxa para ficar abaixo dos limites padrão.
A Azion detecta padrões de autenticação anômala analisando taxas de sucesso e falha de login em conjunto com threat intelligence global — identificando injeção automatizada de credenciais vazadas mesmo quando cada requisição individualmente parece legítima. Isso protege endpoints críticos como /api/login contra abuso em alto volume que limites baseados em IP ignorariam.
Sem observabilidade em tempo real sobre tentativas de autenticação, ataques são investigados depois que já aconteceram. O Real-Time Events oferece janela forense das últimas 168 horas para consulta durante incidentes ativos.
A08: Software and Data Integrity Failures — assuma que o payload quer executar
Falhas de integridade aparecem quando sistemas aceitam dados que não deveriam confiar: artefatos sem assinatura, inputs adulterados ou padrões de desserialização inseguros que acionam caminhos de execução não intencionais. Atacantes usam gadget chains em objetos serializados para provocar execução remota de código sem precisar de credenciais.
O WAF identifica assinaturas maliciosas em corpos de requisição — assinaturas Java rO0 e formatos específicos de serialização PHP. A Rule 13 impõe validação rigorosa dos bodies de POST, garantindo que dados malformados não cheguem ao runtime da aplicação.
A09: Security Logging and Monitoring Failures — se você não vê, não controla
Falhas de logging e monitoramento são a principal causa de invisibilidade de invasões. Sem visibilidade sobre o que está sendo tentado em produção, a detecção depende de efeitos colaterais — e a janela de exposição se estende por semanas.
O Data Stream da Azion transmite logs detalhados de WAF e de acesso em tempo real para SIEMs como Splunk e Datadog, eliminando a latência entre evento e análise. O Real-Time Events oferece consulta forense das últimas 168 horas diretamente na plataforma — permitindo que equipes de segurança acompanhem ataques enquanto acontecem.
A10: Mishandling of Exceptional Conditions — categoria nova no OWASP 2025
A10:2025 é uma das principais novidades do OWASP Top 10 update: tratamento inadequado de condições excepcionais. Atacantes enviam dados malformados intencionalmente para disparar exceções não tratadas que prendem conexões de banco de dados, consomem memória ou travam threads — transformando erros em vetores de exaustão de recursos.
A Azion atua como buffer proativo em duas frentes: a Rule 31 impõe validação estrita de entrada para impedir que dados malformados acionem exceções no backend; quando exceções escapam, a plataforma substitui respostas de erro verbosas por HTML sanitizado antes de chegar ao cliente. O WAF e a Proteção DDoS barram requisições malformadas na borda antes que afetem a disponibilidade da aplicação.
Se o sistema trata exceções como eventos raros, atacantes vão fazer delas o padrão de tráfego.
Como proteger aplicações contra o OWASP Top 10:2025
O OWASP Top 10:2025 deixa claro que proteger aplicações modernas exige mais do que corrigir código. É preciso aplicar políticas de segurança de forma consistente, responder rapidamente a novas ameaças e ter visibilidade contínua sobre o comportamento das aplicações.
A Azion Web Platform entrega isso como plataforma unificada: WAF com análise heurística multicamada, Functions para lógica de autorização no perímetro, Bot Manager para abuso comportamental, e observabilidade ativa via Data Stream e Real-Time Events — tudo em uma arquitetura de segurança distribuída alinhada às categorias do OWASP.
Conheça a Azion Web Platform e veja como implementar uma arquitetura de segurança distribuída alinhada às recomendações do OWASP, ou fale com o nosso time.
Leia também: O que é a lista OWASP Top 10 de ataques web?
Perguntas frequentes
Qual a diferença entre o OWASP Top 10:2021 e o OWASP Top 10:2025? A versão 2025 consolida SSRF dentro de A01 (antes era A10 isolado), amplia o escopo de supply chain para o ciclo de vida completo do software no A03, e introduz A10 como categoria inédita para tratamento inadequado de condições excepcionais. A mudança conceitual central é o foco em riscos arquiteturais e sistêmicos, não apenas em erros de codificação.
O que é virtual patching no contexto do OWASP Top 10:2025? Virtual patching é a aplicação de regras de bloqueio no perímetro de rede enquanto a correção do código subjacente ainda está em andamento. Em vez de esperar o ciclo de patch da dependência vulnerável, o WAF inspeciona requisições em busca de assinaturas do exploit e bloqueia tentativas em tempo real, globalmente.
Como um WAF mitiga falhas de supply chain (A03)? Inspecionando o conteúdo das requisições de entrada em busca de strings associadas a exploits conhecidos — como strings JNDI para Log4Shell ou expressões OGNL para outros CVEs. Quando uma nova vulnerabilidade é publicada, regras de bloqueio são aplicadas no WAF sem necessidade de alterar o código da aplicação ou reiniciar serviços.
O que é config drift e por que ele cria vulnerabilidades? Config drift é a deriva gradual das configurações de infraestrutura em relação a um estado seguro baseline. Um único header ausente ou endpoint admin exposto acidentalmente pode ser suficiente para um atacante ganhar acesso inicial.
O que é a nova categoria A10 do OWASP 2025? Mishandling of Exceptional Conditions — tratamento inadequado de condições excepcionais. É uma categoria inédita que reconhece como o manejo ruim de erros leva à exaustão de recursos: atacantes enviam dados malformados para disparar exceções não tratadas que prendem conexões ou consomem memória de forma deliberada.
