OWASP Top 10 2025: a lista atualizada explicada (A01-A10)

O que é o OWASP Top 10 2025 e o que mudou

O OWASP Top 10 é um documento de conscientização mantido pela comunidade que classifica os riscos de segurança mais críticos para aplicações web. Mantido pelo Open Worldwide Application Security Project, é atualizado a cada três ou quatro anos, aproximadamente, com base em dados de testes de aplicações e em uma pesquisa com profissionais, de modo que cada edição reflete como os invasores realmente agem, e não teoria abstrata.

A edição de 2025 mantém o controle de acesso quebrado no topo e continua tratando categorias inteiras de falhas, e não bugs isolados. As mudanças de destaque são a ênfase maior em configuração insegura na nuvem e no CI/CD, a elevação do risco da cadeia de suprimentos de software para além dos componentes vulneráveis e a atenção explícita a erros e exceções mal tratados que vazam dados silenciosamente ou falham em modo aberto.

Como tantos frameworks e reguladores fazem referência a ele, o Top 10 virou uma base de fato. As expectativas de auditoria do CERT-In na Índia, os requisitos de segurança do RBI e da SEBI, os regimes europeus NIS2 e DORA e os questionários de segurança de grandes empresas norte-americanas pressupõem que suas aplicações foram testadas contra essas categorias. Trate a lista como escopo mínimo, não como linha de chegada.

A01: Controle de acesso quebrado

O controle de acesso define o que um usuário autenticado pode fazer. Ele está quebrado quando um usuário consegue agir além das permissões previstas: ver registros de outros clientes alterando um identificador na URL, escalar para um perfil de administrador ou alcançar APIs que deveriam estar bloqueadas. Segue sendo a categoria mais comum e mais danosa das edições recentes.

Mitigação: negar por padrão e aplicar a autorização no servidor a cada requisição, verificando a propriedade do objeto específico acessado em vez de confiar em identificadores enviados pelo cliente ou em campos ocultos.

A02: Configuração incorreta de segurança

A configuração incorreta abrange padrões inseguros, funcionalidades desnecessárias ativas, páginas de erro detalhadas demais, cabeçalhos de segurança ausentes, armazenamento em nuvem aberto e serviços sem correção ou com privilégios em excesso. A edição de 2025 lhe dá mais destaque porque a expansão de nuvem, contêineres e CI/CD multiplica os lugares onde um único ajuste frágil pode expor dados.

Mitigação: construir bases de configuração endurecidas e reproduzíveis como código, remover componentes sem uso e contas padrão e varrer continuamente os ambientes em execução para detectar desvios antes que um invasor os descubra.

A03: Falhas na cadeia de suprimentos de software

Esta categoria amplia o antigo risco de «componentes vulneráveis e desatualizados» para toda a cadeia de suprimentos de software: bibliotecas de terceiros, imagens base, ferramentas de build, registros de pacotes e os pipelines que os montam. Uma dependência ou etapa de build comprometida pode inserir código malicioso na sua aplicação antes mesmo de ela chegar à produção.

Mitigação: manter uma lista de materiais de software (SBOM), fixar e verificar dependências e proteger o próprio pipeline de build, de modo que só artefatos revisados e com integridade verificada sejam promovidos.

A04: Falhas criptográficas

Falhas criptográficas ocorrem quando dados sensíveis — senhas, dados de pagamento, registros de saúde, dados pessoais sujeitos ao GDPR ou à Lei DPDP da Índia — não são protegidos adequadamente em trânsito ou em repouso. Causas típicas são ausência de criptografia, algoritmos fracos ou obsoletos, chaves embutidas no código e má gestão de chaves.

Mitigação: classificar seus dados, exigir criptografia de transporte forte em todos os pontos, criptografar dados sensíveis em repouso com algoritmos atuais e gerenciar chaves em um serviço dedicado de segredos ou de gestão de chaves, e não no código ou em arquivos de configuração.

A05: Injeção

A injeção ocorre quando uma entrada não confiável é interpretada como comando ou consulta, permitindo ao invasor alterar a lógica do programa. Injeção de SQL, de NoSQL, de comandos do sistema operacional e cross-site scripting estão aqui: a aplicação mistura dados e instruções em vez de mantê-los separados.

Mitigação: usar consultas parametrizadas e APIs seguras que vinculem a entrada como dado, validar entradas contra listas de permissão estritas e codificar a saída conforme o contexto, para que conteúdo fornecido pelo usuário nunca possa ser executado.

A06: Design inseguro

Design inseguro é uma falha da própria arquitetura, não da implementação. Nem mesmo um código perfeito compensa um controle de segurança que nunca foi projetado, como a ausência de limitação de taxa em um fluxo de transferência de dinheiro ou um processo de redefinição de senha passível de abuso para tomar contas.

Mitigação: aplicar modelagem de ameaças desde cedo, definir requisitos de segurança e casos de abuso junto aos funcionais e usar padrões de projeto seguros, para que os controles corretos existam por design e não sejam acrescentados depois.

A07: Falhas de autenticação

Falhas de autenticação permitem que invasores comprometam identidades por meio do mau tratamento de credenciais: permitir senhas fracas ou vazadas, não proteger contra força bruta, tokens de sessão previsíveis ou mal invalidados e ausência de autenticação multifator. O resultado é tomada de contas e credential stuffing em escala.

Mitigação: exigir autenticação multifator, conferir senhas contra listas de vazamentos conhecidos, limitar a taxa e monitorar os endpoints de autenticação e gerar, rotacionar e invalidar tokens de sessão com segurança no servidor.

A08: Falhas de integridade de software e dados

Falhas de integridade surgem quando código ou dados críticos são considerados confiáveis sem verificar se foram adulterados: atualizações automáticas não assinadas, desserialização insegura de objetos não confiáveis ou etapas de CI/CD que baixam artefatos sem verificação de integridade. Um invasor capaz de substituir uma fonte confiável assume o controle da aplicação.

Mitigação: verificar a integridade e a procedência de código, atualizações e dados com assinaturas digitais e nunca desserializar entradas não confiáveis sem controles de tipo estritos e validação.

A09: Falhas de registro e alerta

Esta categoria cobre registro, monitoramento e alerta insuficientes, a razão pela qual tantos incidentes passam meses sem ser detectados. Se falhas de autenticação, violações de controle de acesso e transações de alto valor não são registradas, e alertas não são gerados, um ataque em andamento fica invisível para os defensores.

Mitigação: registrar eventos relevantes para a segurança com contexto suficiente para investigar, centralizar e proteger esses registros e conectá-los a alertas em tempo real e a um processo de resposta a incidentes, obrigação reforçada pela exigência do CERT-In de reter logs na Índia por 180 dias.

A10: Tratamento inadequado de condições excepcionais

A edição de 2025 chama atenção explícita para como as aplicações tratam erros e condições excepcionais. Um tratamento ruim de erros pode vazar rastros de pilha, caminhos internos e detalhes de configuração para invasores, ou fazer a lógica falhar em modo aberto, concedendo acesso quando uma verificação falha em vez de negá-lo. Nos dois casos, um caso de borda vira um evento de segurança.

Mitigação: falhar de forma segura e fechada, devolver mensagens de erro genéricas aos usuários enquanto registra o detalhe completo no servidor e testar deliberadamente entradas excepcionais e inesperadas, não apenas o caminho feliz.

Como a IntelligenceX ajuda

O OWASP Top 10 2025 é um mapa de onde olhar, mas a cobertura só conta se suas aplicações forem de fato testadas contra ele. A IntelligenceX avalia cada categoria por meio de serviços de base manual alinhados ao OWASP e entrega remediação pronta para desenvolvedores, uma abordagem adequada a compradores do Reino Unido, dos EUA, da UE e da Índia.

Nosso teste de intrusão de aplicações web exercita cada categoria do Top 10 na sua aplicação em produção, do controle de acesso quebrado e da injeção às falhas de registro e de tratamento de exceções, com evidências de prova de conceito e um reteste de remediação gratuito. Nossa revisão de código seguro examina o próprio código-fonte para detectar falhas criptográficas, de injeção e de integridade que o teste caixa-preta pode não alcançar. Nossa modelagem de ameaças enfrenta de frente o A06 Design inseguro, revelando controles ausentes antes de serem escritos em código.

Para organizações reguladas na Índia, esse teste se encaixa diretamente nos deveres de salvaguarda de segurança da Lei DPDP e nas expectativas do CERT-In, do RBI, da SEBI e do IRDAI. Para deixar o escopo claro: a IntelligenceX assessora, avalia e prepara, e atualmente não é credenciada pelo CERT-In; não emitimos certificados nem assinamos auditorias regulatórias. Fale com nossa equipe para definir o escopo de uma avaliação das suas aplicações.