Depuis sa création au début des années 2000, le projet OWASP (Open Web Application Security Project) publie régulièrement un classement des dix risques les plus critiques pour la sécurité des applications web – le fameux « Top 10 ».
La version 2025, dévoilée récemment en tant que release candidate, marque la huitième édition de ce référentiel.
L’objectif reste identique : fournir aux développeurs, architectes, équipes de sécurité et décideurs un cadre de référence pour identifier, prioriser et corriger les vulnérabilités les plus dangereuses dans leurs applications.
Mais cette nouvelle édition introduit des changements notables – des catégories redéfinies, des priorités recalculées, et deux nouveaux types de risques, pour s’adapter à l’évolution rapide des technologies, des méthodes de développement et des chaînes logicielles.
Le Top 10 2025 : risques par ordre de gravité
Voici la liste des 10 catégories retenues en 2025 (par ordre de priorité) :
| Rang | Catégorie (2025) | Description générale |
|---|---|---|
| A01 | Broken Access Control (contrôles d’accès défaillants) | Mauvaise gestion des permissions et des droits d’accès, permettant des actions non autorisées. |
| A02 | Security Misconfiguration (mauvaise configuration de sécurité) | Paramétrages ou configurations d’infrastructures, serveurs, frameworks ou bibliothèques incorrects ou trop permissifs. |
| A03 | Software Supply Chain Failures | Vulnérabilités dans la chaîne d’approvisionnement logicielle : dépendances, bibliothèques externes, outils de build/distribution, etc. |
| A04 | Cryptographic Failures (défaillances cryptographiques) | Mauvaise utilisation du chiffrement, gestion des clés, stockage de données sensibles non sécurisé, etc. |
| A05 | Injection | Failles typiques comme SQL Injection, Cross-site Scripting (XSS), etc., où des données non fiables sont interprétées comme du code. |
| A06 | Insecure Design (conception non sécurisée) | Absence de principes de sécurité dès la phase de design/architecture, absence de modélisation des menaces, mauvaise conception logique. |
| A07 | Authentication Failures (échecs d’authentification) | Défauts dans la gestion des authentifications et identifications — authentification faible, sessions non protégées, etc. |
| A08 | Software or Data Integrity Failures (intégrité logiciel / données compromise) | Problèmes liés à l’intégrité du code, des mises à jour, des bibliothèques, ou des données, risquant de corrompre l’application. |
| A09 | Logging & Alerting Failures (journalisation et alertes insuffisantes) | Absence ou insuffisance des logs et alertes, rendant la détection d’attaques, la traçabilité ou l’analyse d’incidents difficile. |
| A10 | Mishandling of Exceptional Conditions (mauvaise gestion des conditions exceptionnelles) | Gestion incorrecte des erreurs, des cas limites ou des situations imprévues — erreurs d’implémentation, « failing open », comportements non sécurisés. |
Ce qui change — et pourquoi ces évolutions sont pertinentes
Une réorganisation logique
• La catégorie « Software Supply Chain Failures » remplace et élargit l’ancienne « Vulnerable and Outdated Components » (composants vulnérables / obsolètes). L’idée est de couvrir désormais l’ensemble de l’écosystème logiciel – pas seulement les bibliothèques tierces, mais aussi les outils de build, les pipelines, les registres de paquets, les processus de distribution… bref, tout ce qui intervient dans la chaîne de production logicielle.
• La catégorie « Mishandling of Exceptional Conditions » est une nouveauté. Elle met en lumière des zones souvent négligées : la gestion des erreurs, des exceptions, des cas imprévus — des failles logiques pouvant compromettre la sécurité si mal traitée.
Des priorités redéfinies
• Broken Access Control reste en tête – c’est encore la cause principale de brèches graves. Selon les données agrégées par OWASP, environ 3,73 % des applications testées présentent au moins une vulnérabilité relevant des 40 CWEs (Common Weakness Enumerations) de cette catégorie.
• Security Misconfiguration gagne du terrain, passant du rang 5 (dans la version 2021) au rang 2 en 2025, illustrant la recrudescence de failles liées à des configurations incorrectes, mal sécurisées ou trop permissives.
• Injection, longtemps considéré comme le fléau majeur des applications web, descend à la 5ᵉ place. Cela suggère que, bien que toujours critique, les pratiques de développement et de détection se sont améliorées.
Une approche plus centrée sur les causes racines
L’un des principes de cette mise à jour est de se focaliser davantage sur les causes profondes (root causes) plutôt que sur les symptômes. Ainsi, au lieu d’avoir des catégories comme « exposition de données sensibles », on traite les véritables origines : chiffrement mal configuré, absence de gestion des accès, mauvaise conception, etc.
De plus, le nombre de CWEs examinées a fortement augmenté (passant d’environ 30 en 2017, à près de 400 en 2021, puis 589 pour cette version 2025), ce qui reflète la complexité croissante des environnements logiciels modernes – et la nécessité d’un cadre plus large et plus précis.
Pourquoi cette mise à jour est cruciale aujourd’hui
• Évolution des chaînes logicielles : Les applications modernes reposent souvent sur des centaines de dépendances, des micro-services, des conteneurs, des pipelines CI/CD, des registres de paquets… Autant d’éléments qui peuvent introduire des failles. En adoptant « Supply Chain Failures », OWASP prend en compte une réalité de développement plus complexe.
• Complexité croissante des architectures : Les architectures distribuées, les micro-services, les APIs externes, le cloud, les intégrations tierces… tout cela multiplie les surfaces d’attaque. Les erreurs de conception, de configuration ou d’erreur d’exception peuvent avoir des conséquences majeures.
• Meilleure maturité des défenses traditionnelles : Les injections, les failles cryptographiques et autres classiques sont mieux connues — les développeurs et responsables sécurité les anticipent donc davantage. Cela explique en partie la baisse de leur poids relatif dans le classement.
• Besoin de standards actualisés : Utiliser une version ancienne du Top 10, c’est ignorer des risques récents ou sous-estimés. Pour toute organisation soucieuse de maintenir un niveau de sécurité moderne, la version 2025 doit devenir le nouveau référentiel de base.
Pour qui ce classement est-il utile – et comment l’utiliser au mieux
• Pour les développeurs : intégrer dès la phase de conception des réflexes de sécurité (contrôles d’accès, gestion des erreurs, configuration sécurisée, vérification des dépendances, etc.).
• Pour les équipes DevSecOps / SRE / sécurité : prioriser les audits, les tests d’intrusion, les revues de code et les analyses de dépendances autour de ces catégories.
• Pour les architectes logiciels : s’assurer que l’architecture adoptée minimise l’impact en cas de faille, qu’elle facilite la surveillance, la journalisation, la gestion des erreurs, la mise à jour des composants, etc.
• Pour les décideurs / managers IT : utiliser le Top 10 comme référence pour définir des politiques de sécurité, des exigences contractuelles, des critères d’évaluation de fournisseurs ou de prestataires.
En pratique, le document OWASP propose de l’utiliser non pas comme une liste figée de points à cocher, mais comme un outil d’éducation, de sensibilisation et de gouvernance.
Limites et défis à garder en tête
• Même si le classement se base sur des données collectées (applications testées, vulnérabilités identifiées), certaines catégories restent difficiles à mesurer — notamment celles liées à la chaîne logicielle, à la conception ou à l’intégrité des données / du code. La faible occurrence de données dans ces catégories ne signifie pas qu’elles sont moins dangereuses : souvent, elles sont moins bien testées. owasp.org+1
• Toutes les failles ne sont pas identifiées par les outils automatiques : des études montrent que certains outils d’analyse statique, même combinés, détectent moins de 60 % des vulnérabilités dans des projets réels. arXiv
• Le Top 10 reste un minimum de sécurité — ce n’est pas suffisant pour garantir qu’une application est totalement sécurisée. Il doit être complété par des pratiques de sécurisation plus larges : revue de code, tests dynamiques, processus de mise à jour, surveillance continue, gestion des incidents, etc.
Conclusion
La publication de l’OWASP Top 10 : 2025 (même sous forme de release candidate) est un événement important pour la communauté de la cybersécurité et pour tous ceux qui développent ou maintiennent des applications web. Elle traduit l’évolution des menaces, l’augmentation de la complexité des applications modernes et la nécessité d’adapter nos réflexes de sécurité.
En plaçant désormais la chaîne logicielle, la configuration, la conception, la gestion des erreurs et l’intégrité au même niveau que les failles classiques, OWASP invite à repenser la sécurité dès l’architecture, et non seulement à la fin du cycle de développement.
Pour rester pertinent face aux menaces de 2025 et au-delà, tout projet sérieux devrait se baser sur cette nouvelle version tant pour l’analyse des risques, que pour les bonnes pratiques de développement, de déploiement et de maintenance.
