L'OWASP Top 10 est le document de référence qui recense les dix risques de sécurité les plus critiques pour les applications web. Annoncé en novembre 2025 lors de la conférence OWASP Global AppSec à Washington, puis finalisé en janvier 2026, le nouveau OWASP Top 10 2025 est la première révision majeure du classement depuis 2021. Rien d'exceptionnel en apparence : le Top 10 existe depuis 2003 et fait l'objet de révisions périodiques sur les risques de sécurité les plus critiques pour les applications web. Sauf que l'écart de quatre ans avec l'édition précédente représente une fenêtre pendant laquelle une part substantielle des dispositifs de formation des développeurs, des règles d'analyse statique intégrées aux pipelines CI/CD et des grilles d'audit internes est restée calée sur une cartographie de la menace que les données récentes contredisent.

Si votre dernier cycle de sensibilisation des équipes de développement remonte à avant 2025, il y a de fortes chances qu'il omette deux catégories de risque désormais explicitement référencées, et qu'il maintienne l'injection en troisième position alors qu'elle a reculé d'office. Comprendre l'évolution de ces risques conditionne directement l'efficacité de tout programme de sécurité applicative.

• Première révision majeure depuis 2021, fondée sur plus de 175 000 CVE analysées. Au total, 589 CWE ont été examinées (contre environ 400 en 2021), dont 248 cartographiées dans les dix catégories finales.

• Deux nouvelles catégories entrent au classement : les défaillances de la chaîne d'approvisionnement logicielle (A03) et la mauvaise gestion des conditions exceptionnelles (A10).

• Le SSRF (Server-Side Request Forgery) disparaît comme catégorie autonome : il est absorbé dans le contrôle d'accès défaillant (A01).

• La mauvaise configuration de sécurité bondit de la 5ᵉ à la 2ᵉ place ; l'injection recule de la 3ᵉ à la 5ᵉ.

• Le contrôle d'accès défaillant reste en tête, pour la quatrième édition consécutive.

Le classement 2025 reste structuré en dix catégories :

• A01 — Contrôle d'accès défaillant (Broken Access Control) — était A01 en 2021. Stable, 1ère place depuis 4 éditions. Absorbe désormais le SSRF.

• A02 — Mauvaise configuration de sécurité (Security Misconfiguration) — était A05. Bond de 3 places.

• A03 — Défaillances de la chaîne d'approvisionnement logicielle (Software Supply Chain Failures) — nouvelle catégorie, extension de A06:2021.

• A04 — Défaillances cryptographiques (Cryptographic Failures) — était A02. Recul de 2 places.

• A05 — Injection — était A03. Recul de 2 places.

• A06 — Conception non sécurisée (Insecure Design) — était A04. Recul de 2 places.

• A07 — Défaillances d'authentification (Authentication Failures) — était A07. Stable.

• A08 — Défaillances d'intégrité logiciel/données (Software and Data Integrity Failures) — était A08. Stable.

• A09 — Défaillances de journalisation et d'alerte (Security Logging and Alerting Failures) — était A09. Renommée (Monitoring → Alerting).

• A10 — Mauvaise gestion des conditions exceptionnelles (Mishandling of Exceptional Conditions) — nouvelle catégorie, remplace le SSRF.

Le classement n'est pas purement piloté par les données. OWASP a d'abord ordonné une série de catégories à partir des seules données collectées, puis a réservé deux des dix places à des risques mis en avant par l'enquête communautaire (quitte à ce qu'ils soient encore sous-représentés dans les données). La raison est assumée : analyser des données revient à regarder le passé. Entre le moment où une nouvelle classe de vulnérabilité émerge et celui où l'industrie sait la tester à grande échelle, il s'écoule souvent plusieurs années. C'est précisément ce décalage qui explique l'arrivée de la chaîne d'approvisionnement et de la gestion des conditions exceptionnelles.

C'est le mouvement le plus marqué du classement, et il révèle quelque chose de précis sur la façon dont les applications contemporaines sont déployées. Selon les données OWASP, environ 3 % des applications testées présentaient au moins l'une des 16 CWE de cette catégorie. Une prévalence en hausse sur ce cycle, suffisante pour faire passer la mauvaise configuration devant les défaillances cryptographiques.

Ce que recouvre la catégorie n'a rien de sophistiqué : buckets cloud laissés en accès public, comptes par défaut jamais désactivés, en-têtes HTTP mal configurés, messages d'erreur trop verbeux qui exposent l'architecture interne. Aucune de ces failles n'exige une attaque élaborée, simplement un examen de ce qui a été omis lors de la configuration.

La cause structurelle de cette progression tient au déséquilibre entre déploiement continu et contrôle continu. À mesure que la logique applicative migre vers des fichiers de configuration, des permissions cloud et des templates d'infrastructure (IaC), chaque drapeau mal positionné devient un vecteur potentiel. Une organisation qui pousse en production plusieurs fois par jour mais n'audite ses configurations qu'une fois par trimestre génère mécaniquement une fenêtre d'exposition active entre deux vérifications. Plus la cadence de déploiement s'accélère, plus cette fenêtre s'élargit si la surveillance ne progresse pas en proportion.

La nouvelle catégorie A03 étend ce qui s'appelait en 2021 « composants vulnérables et obsolètes » pour englober désormais l'ensemble de l'écosystème qui construit, distribue et met à jour un logiciel : une dépendance compromise, une mise à jour non signée, un pipeline de build infiltré, un registre détourné.

Voici le point que beaucoup d'articles ratent — et le plus instructif. Dans les données OWASP, cette catégorie affiche le plus faible nombre d'occurrences du classement, parce qu'elle reste difficile à tester à grande échelle. Pourtant, elle a été massivement plébiscitée comme préoccupation prioritaire dans l'enquête communautaire, et les CVE qui s'y rattachent présentent les scores d'exploitabilité et d'impact les plus élevés de tout le Top 10. Autrement dit : ce risque devance structurellement les outils censés le détecter. OWASP a fait le choix assumé de le promouvoir malgré sa sous-représentation dans les données, parce que les professionnels du terrain le voyaient déjà arriver.

Les chiffres 2025-2026 leur donnent raison, et de façon spectaculaire :

• Le rapport Sonatype 2026 State of the Software Supply Chain recense plus de 454 600 nouveaux paquets open source malveillants en 2025, soit une hausse de 75 % en un an, pour un cumul dépassant 1,23 million de paquets bloqués. Plus de 99 % de ces malwares se concentrent sur npm.

• Le Verizon DBIR 2025 indique que 30 % des compromissions impliquent désormais un tiers, soit le double des 15 % de l'année précédente — le plus fort bond annuel de l'histoire du rapport.

• Selon le IBM Cost of a Data Breach 2025, une compromission de la chaîne d'approvisionnement coûte en moyenne 4,91 M$ et met 267 jours à être identifiée et contenue — le cycle de vie le plus long de tous les vecteurs suivis.

Le ver Shai-Hulud, apparu sur npm en septembre 2025, a marqué un tournant : premier malware auto-réplicatif natif d'un registre, il vole les jetons des mainteneurs pour republier automatiquement des versions empoisonnées de tous leurs paquets. Ses vagues successives — « Second Coming » fin 2025, Mini Shai-Hulud au printemps 2026, puis des variantes comme Miasma et l'incident Red Hat de juin 2026 — ont compromis des milliers de paquets et exposé des dizaines de milliers de dépôts en aval.

Deux enseignements pour 2026, qui prolongent directement le constat d'OWASP :

1. Les attaques supply chain les plus marquantes n'ont, au moment de leur exploitation, aucun CVE. L'incident Trivy est emblématique : un scanner de vulnérabilités lui-même détourné pour distribuer du vol d'identifiants dans des milliers de workflows CI/CD, dont la CVE (CVE-2026-33634) n'a été assignée et ajoutée au catalogue CISA KEV qu'après coup. Un programme qui n'audite que les vulnérabilités déjà cataloguées arrive systématiquement en retard.

2. L'IA devient une surface d'attaque à part entière. L'ENISA Threat Landscape 2025 documente l'empoisonnement de modèles, les attaques de type « Rules File Backdoor » contre les assistants de codage IA, et le slopsquatting — l'enregistrement de paquets aux noms hallucinés par les LLM, que les développeurs installent sans vérifier.

La seconde nouvelle catégorie, A10, regroupe 24 CWE couvrant les défaillances qui surviennent lorsqu'une application rencontre une situation imprévue et la traite mal : une exception non interceptée qui révèle une trace de pile complète à l'utilisateur, une condition de concurrence (race condition) qui corrompt un état interne, un mécanisme qui « échoue en mode ouvert » (fail open) et accorde l'accès en cas d'erreur.

Le risque ne réside pas tant dans la survenue de l'erreur que dans l'absence de réponse anticipée. Les développeurs concentrent naturellement leurs tests sur les happy paths : entrées valides, comportements attendus. Or les attaquants vivent dans les cas limites : ils sondent ce qui se passe quand le système échoue. C'est exactement ce vide que cette catégorie vient nommer.

Elle remplace le SSRF en dixième position. Pour autant, le SSRF n'a pas disparu du référentiel : il a été absorbé dans le contrôle d'accès défaillant (A01), OWASP considérant désormais qu'il relève fondamentalement d'une défaillance de contrôle d'accès plutôt que d'un risque autonome. Les pratiques de défense restent les mêmes : liste blanche des destinations sortantes, restriction de l'accès aux métadonnées cloud, validation des schémas d'URL.

Si votre programme AppSec demeure calé sur le référentiel 2021, trois ajustements s'imposent.

Vos règles d'analyse statique doivent être recartographiées. Les règles qui pointaient vers le SSRF en A10:2021 doivent désormais être rattachées à A01:2025, et de nouvelles règles couvrant la chaîne d'approvisionnement et la gestion des exceptions doivent être activées. Les principaux éditeurs de SAST (Parasoft, Semgrep, et d'autres) ont déjà publié des packs de conformité mis à jour pour 2025 ; s'appuyer sur du SAST sans cette mise à jour revient à auditer son code contre une cartographie en retard de quatre ans.

Votre dispositif de scan de dépendances doit s'étendre à toute la chaîne. Une analyse classique de composants tiers (SCA), centrée sur les seules vulnérabilités déjà cataloguées, ne suffit plus. Il faut désormais intégrer la génération de SBOM (l'inventaire exhaustif des composants logiciels), la vérification de signature des dépendances, et une vigilance accrue sur le dependency confusion, le typosquatting et le slopsquatting. À noter : la vérification de provenance (type SLSA) reste nécessaire mais n'est plus suffisante. Certaines vagues Shai-Hulud ont produit des paquets dotés d'une provenance valide. L'analyse comportementale au moment de l'installation devient déterminante.

Votre revue de code doit intégrer une grille pour les conditions exceptionnelles. Exceptions non interceptées, race conditions, anomalies de type TOCTOU, politique de gestion des erreurs : ces éléments constituent désormais des risques explicitement nommés, que les relecteurs doivent vérifier systématiquement. Adopter des design patterns sécurisés dès la conception réduit structurellement l'exposition à ces deux nouvelles catégories.

Dans la pratique, c'est précisément l'écart entre ce que le code prétend couvrir et ce qui s'avère réellement exploitable depuis l'extérieur qui justifie une surveillance continue plutôt qu'un audit calé sur le cycle de publication d'OWASP. Un test dynamique (DAST) déployé en continu détecte une mauvaise configuration ou une défaillance d'accès dès qu'elle devient exploitable, sans attendre la prochaine révision du référentiel. C'est aussi le moyen le plus direct de réduire le risque d'exposition de données sensibles, conséquence la plus fréquente de la majorité des catégories du classement.

« Le Top 10 d'OWASP reste un document de sensibilisation, pas un référentiel de conformité complet. Le vrai travail commence après l'avoir lu : vérifier que ce qu'on croit couvrir correspond à ce qui est réellement exposé sur le périmètre. »
— Vladimir Kolla, cofondateur de Patrowl

Le Top 10 OWASP 2025 ne se contente pas de réorganiser un classement. Il acte un déplacement de fond : la sécurité applicative ne se joue plus uniquement dans le code produit, mais dans la façon dont ce code est construit, dans le choix des dépendances et dans la configuration de l'infrastructure de déploiement. Les deux nouvelles catégories ne sont pas des ajouts cosmétiques : elles documentent des attaques qui se produisent déjà en production, comme le confirment les vagues Shai-Hulud et l'explosion des paquets malveillants en 2025-2026.

Actualiser ses règles de scan, sa formation des développeurs et ses priorités de revue de code ne relève donc pas d'un exercice de conformité formel. Il s'agit d'aligner son programme de sécurité applicative sur une cartographie de la menace qui accuse, de fait, quatre années de retard si elle n'a pas évolué depuis 2021.

À quelle fréquence l'OWASP Top 10 est-il mis à jour ?
Environ tous les trois à quatre ans. Les éditions précédentes datent de 2003, 2004, 2007, 2010, 2013, 2017 et 2021. La fréquence dépend des cycles de collecte de données et des évolutions du paysage des menaces. L'édition 2025 est la huitième.

Quelles sont les deux nouvelles catégories du Top 10 2025 ?
Les défaillances de la chaîne d'approvisionnement logicielle (A03), qui étend l'ancienne catégorie des composants vulnérables, et la mauvaise gestion des conditions exceptionnelles (A10), qui couvre les exceptions non interceptées, les race conditions et les politiques de gestion d'erreurs absentes.

Qu'est-il arrivé au SSRF dans le Top 10 2025 ?
Il a été absorbé dans le contrôle d'accès défaillant (A01), OWASP considérant qu'il relève fondamentalement d'une défaillance de contrôle d'accès. Les pratiques de défense restent inchangées : liste blanche des destinations sortantes, restriction de l'accès aux métadonnées cloud, validation des schémas d'URL.

Pourquoi la mauvaise configuration de sécurité est-elle passée de la 5ᵉ à la 2ᵉ place ?
Parce que sa prévalence a augmenté sur ce cycle de données (environ 3 % des applications testées présentaient au moins l'une de ses CWE) et parce que le déploiement continu sans contrôle continu crée une fenêtre d'exposition qui s'élargit avec le rythme des déploiements et la généralisation de l'infrastructure as code.

Pourquoi la chaîne d'approvisionnement est-elle classée si haut alors qu'elle est peu présente dans les données ?
Parce qu'OWASP ne se fie pas uniquement aux données historiques. Cette catégorie affiche peu d'occurrences (elle reste difficile à tester), mais les CVE associées ont les scores d'exploitabilité et d'impact les plus élevés du classement, et elle a été plébiscitée par l'enquête communautaire. Les chiffres 2025-2026 confirment ce choix : +75 % de paquets open source malveillants en un an selon Sonatype.

Le Top 10 OWASP est-il une norme de conformité ?
Non. OWASP le présente explicitement comme un document de sensibilisation, pas un cadre complet. Des référentiels comme PCI DSS 4.0, SOC 2 ou HIPAA reconnaissent la couverture du Top 10 comme une preuve de bonnes pratiques, mais pour aller plus loin OWASP recommande des modèles de maturité complémentaires comme SAMM, DSOMM ou ASVS.

Sources : OWASP Top 10:2025 (owasp.org/Top10/2025) · Sonatype 2026 State of the Software Supply Chain Report · Verizon 2025 DBIR · IBM Cost of a Data Breach 2025 · ENISA Threat Landscape 2025 · Unit 42 (Palo Alto Networks), Parasoft, Semgrep, GitLab, Fluid Attacks.