Les Top 10 de l’OWASP : une trentaine de listes, un seul nom

Dire « le Top 10 OWASP » en réunion revient à dire « la norme ISO » : tout le monde hoche la tête, et personne ne parle du même document. Il n’y a pas un Top 10 de l’OWASP, il y en a une trentaine. Chacun couvre une surface — le web, les interfaces de programmation, le mobile, un orchestrateur de conteneurs, une chaîne de livraison, un modèle de langage, un agent — avec son propre vocabulaire, sa propre numérotation et son propre rythme de révision. Certains sortent une édition tous les quatre ans après analyse de millions d’applications ; un autre porte encore la mention « brouillon » trois ans après son dernier remaniement.

→ Lire l’explication complète de la marmotte

Pourquoi une trentaine de listes et pas une seule

L’OWASP est une fondation à but non lucratif portée par des bénévoles, des chapitres locaux et des mainteneurs de projets. Elle n’a ni autorité réglementaire, ni comité central qui arbitrerait un périmètre unique. Quand une communauté se forme autour d’une surface mal couverte — les interfaces de programmation en 2019, Kubernetes en 2022, les modèles de langage en 2023, le protocole MCP en 2025 — elle monte un projet, et ce projet produit généralement un Top 10. C’est le format que l’OWASP a rendu célèbre, donc c’est le format qu’on reprend.

Cette prolifération n’est pas un désordre, c’est une conséquence de la méthode. Un Top 10 classe des classes de défaut observées sur une surface donnée, et la surface décide du vocabulaire. Le Top 10 web parle de contrôle d’accès, d’injection et de mauvaise configuration. Celui des interfaces de programmation parle d’autorisation au niveau de l’objet, de la propriété et de la fonction — trois granularités que le web ne distingue pas. Celui de Kubernetes parle de politiques de cluster et de mouvement latéral vers le cloud, deux notions que le Top 10 web n’a aucune raison de connaître. Fusionner tout cela produirait dix entrées si générales qu’elles ne trieraient plus rien.

La seconde raison est de rythme. Le Top 10 web est révisé tous les quatre ans parce qu’il attend des données : il faut que l’industrie sache tester une faiblesse à grande échelle avant qu’elle apparaisse dans les chiffres. Les listes consacrées à l’intelligence artificielle sortent une édition par an parce que leur objet change plus vite que la capacité à le mesurer. Mettre les deux sous le même cycle appauvrirait l’un et périmerait l’autre.

Reste un effet de bord inconfortable : le même code peut désigner deux choses. « A03 » désigne la chaîne d’approvisionnement logicielle dans l’édition 2025 du Top 10 web, et l’injection dans celle de 2021. « LLM03 » désigne l’agentivité excessive en 2026 et la chaîne d’approvisionnement en 2025. Un ticket qui dit « corriger A03 » demande de corriger quelque chose, mais on ne sait pas quoi. D’où la règle qui gouverne toutes les pages ci-dessous : le code sans l’édition ne veut rien dire.

Les référentiels traités ici

Dix listes, une page chacune. Chaque page donne le tableau complet des dix entrées avec le titre officiel anglais et sa traduction, l’édition décrite, et ce qui a changé depuis la précédente quand c’est documenté.

Référentiel	Codes	Édition courante	Date
Top 10 web	A01 – A10	2025	présentée le 6 novembre 2025
API Security Top 10	API1 – API10	2023	2023 (2ᵉ édition)
Top 10 LLM et IA génératives	LLM01 – LLM10	2026	4 août 2026
Top 10 des applications agentiques	ASI01 – ASI10	2026	décembre 2025
Mobile Top 10	M1 – M10	2024	2024
Kubernetes Top 10	K01 – K10	2025	2025
Top 10 CI/CD	CICD-SEC-1 – 10	unique	2022
MCP Top 10	MCP01 – MCP10	2025 (bêta)	2025
Machine Learning Security Top 10	ML01 – ML10	2023 (brouillon)	2023
Non-Human Identities Top 10	NHI1 – NHI10	2025	2025
Open Source Software Top 10	OSS-RISK-1 – 10	unique	2023

Le Top 10 des applications agentiques est traité par sa propre page chapeau et une page par risque : c’est le plus récent des référentiels d’intelligence artificielle de l’OWASP, et le seul qui décrive un programme qui agit plutôt qu’un modèle qui répond.

Ce qu’un Top 10 n’est pas

Un Top 10 de l’OWASP n’est ni une norme opposable, ni une certification, ni un plan de remédiation. Aucune de ces listes ne crée d’obligation : il n’existe pas d’organisme qui atteste qu’une application « respecte le Top 10 », parce qu’il n’y a rien à attester. La formulation elle-même est un indice : une liste de risques se traite, elle ne se respecte pas. Pour l’articulation avec une obligation réelle — directive NIS 2, règlement sur la cyberrésilience, règlement sur l’intelligence artificielle — c’est la rubrique Normes qui porte le sujet, et elle ne cite jamais un Top 10 comme source de droit.

Ce n’est pas non plus un référentiel d’exigences. Une entrée de Top 10 nomme une classe de défaut ; elle ne dit pas quelle propriété vérifier, ni comment, ni avec quelle preuve. C’est le travail de l’ASVS (Application Security Verification Standard) pour le web, du MASVS pour le mobile, du SCVS pour les composants logiciels. Le Top 10 sert à décider de quoi on parle ; ces standards servent à décider ce qu’on exige. Confondre les deux produit la matrice de conformité la plus répandue du métier : dix cases cochées, zéro preuve derrière.

Ce n’est pas un classement de gravité pour un système donné. Les rangs sortent de données agrégées sur des millions d’applications ou d’un vote de praticiens, pas de l’architecture qu’on a sous les yeux. A01 en tête ne signifie pas que le contrôle d’accès est le premier problème ici : il signifie qu’il l’est en moyenne, chez les autres.

Enfin, ce n’est pas une garantie d’exhaustivité. Les dix entrées couvrent ce que la communauté voit et sait tester. La fraude métier, l’abus de fonction légitime, le remboursement autorisé par une règle commerciale absurde : rien de tout cela n’apparaît, parce que rien de tout cela n’est une faiblesse technique. Une application peut traiter ses dix catégories et perdre de l’argent par conception.

La maturité est inégale, et le dépôt le dit

C’est le point que les présentations omettent. Ces listes portent le même logo et le même format, mais pas le même niveau d’entretien. La notoriété n’est pas un mécanisme de gestion de versions. Trois signaux se lisent en quelques minutes, sans croire personne sur parole.

Le premier est le niveau du projet, affiché sur sa page : Flagship, Production, Lab, Incubator. Le Top 10 web est un projet Flagship, le plus haut niveau. Le Top 10 CI/CD est un projet Lab, ceux de Kubernetes et des identités non humaines des projets Incubator. Ce n’est pas un jugement de qualité — le Top 10 CI/CD est l’un des documents les plus utiles de la liste — mais une indication de l’engagement que la fondation prend sur son entretien.

Le deuxième est la méthode déclarée. Le Top 10 web 2025 repose sur des données portant sur plus de 2,8 millions d’applications, huit catégories issues des chiffres et deux promues par un sondage communautaire. L’édition 2026 du Top 10 LLM croise un vote de praticiens, pondéré aux trois quarts, avec un corpus de 6 639 incidents réels classés automatiquement. À l’autre extrémité, l’API Security Top 10 de 2023 a lancé un appel public à données auquel personne n’a répondu : ses auteurs le disent dans leurs notes de version et assument une liste bâtie sur le consensus de l’équipe. C’est honnête, et cela change la façon de citer le document.

Le troisième est la date de dernière modification du dépôt. Le Top 10 Machine Learning porte encore, sur son propre site, la mention « brouillon, version 0.3, modifié fréquemment » : la liste des dix entrées n’a pas bougé depuis 2023. Le MCP Top 10 annonce sur sa feuille de route qu’il est en phase 3 sur cinq, c’est-à-dire en version bêta, et le titre de son entrée MCP06 a changé entre deux relevés à quelques mois d’intervalle. Le Top 10 CI/CD n’a jamais eu de deuxième édition depuis 2022, ce qui n’est pas un abandon : la chaîne de livraison logicielle a moins bougé que l’intelligence artificielle, et les dix risques tiennent encore.

Rien de tout cela ne disqualifie ces documents. Cela décide comment les citer : un Top 10 Incubator en brouillon est une grille de lecture utile, pas une référence à inscrire dans un cahier des charges sans précaution.

Quelle liste pour quelle surface

Le choix se fait sur la surface, pas sur la technologie à la mode. Une application web avec une interface de programmation et un client mobile relève des trois listes correspondantes, et les trois disent des choses différentes de la même authentification. Une plateforme qui héberge cette application relève du Top 10 Kubernetes ; la chaîne qui la livre, du Top 10 CI/CD ; les dépendances qu’elle embarque, du Top 10 open source. Les identités qui font tourner tout cela relèvent du Top 10 des identités non humaines — c’est la liste la moins connue et l’une des plus directement actionnables.

Du côté de l’intelligence artificielle, la frontière est explicite depuis l’édition 2026 du Top 10 LLM, qui la pose en toutes lettres : tant que le modèle est un composant de l’application, le risque relève du Top 10 LLM ; dès qu’il devient un acteur, avec des outils qu’il appelle, une mémoire qu’il conserve et des conséquences qu’il déclenche, le risque relève du Top 10 des applications agentiques. Le Top 10 Machine Learning, lui, ne vise ni l’un ni l’autre : il vise le modèle comme objet — son entraînement, son vol, l’inférence de ce qu’il a mémorisé. Le MCP Top 10 vise la tuyauterie entre les deux.

Pour passer d’un code à une décision, le chemin est toujours le même : relier l’entrée du Top 10 à une exigence vérifiable, puis à une preuve. Comment lire un rapport de scan décrit ce passage pour le web ; il se transpose aux autres listes sans difficulté.

Les listes qu’on ne traite pas ici

L’OWASP en publie d’autres, nommées ici pour qu’on sache qu’elles existent : Smart Contract, Serverless, Docker, Data Security, Desktop App, Thick Client, Client-Side, Privacy Risks, Operational Technology, Infrastructure, Cloud-Native, Business Logic Abuse, Maritime, Citizen Development, Agentic Skills. Certaines sont actives, d’autres dorment — le dépôt de la liste consacrée à la vie privée n’a rien reçu depuis 2022. Elles couvrent des surfaces que le site ne traite pas, ou pas encore.

🐝 Ce qui arrive si on s’en passe

Sans distinguer les listes, « le Top 10 OWASP » devient un mot de passe de réunion : chacun pense à la sienne, et la mesure retenue protège une surface que personne n’exploitait. Sans citer l’édition, un code de catégorie devient ambigu — « A03 » et « LLM03 » ont changé de sens entre deux éditions — et un ticket de correction ne désigne plus rien de précis ; six mois plus tard, personne ne sait si le correctif visait l’injection ou la chaîne d’approvisionnement. Sans regarder le niveau du projet et la date du dépôt, un brouillon de 2023 se cite comme un référentiel entretenu, et une exigence contractuelle finit adossée à un document que plus personne ne révise. Sans la distinction entre liste de risques et référentiel d’exigences, la conformité se résume à dix cases cochées sans preuve : aucune vérification n’est reproductible, aucune régression n’est démontrable, et la première question d’un auditeur fait tomber l’ensemble.

🦫 Explication de la marmotte 🍫

Une association internationale de spécialistes en sécurité informatique, l’OWASP, publie des listes des dix problèmes les plus graves pour différentes sortes de logiciels. Il existe une liste pour les sites web, une pour les téléphones, une pour les interfaces que les programmes utilisent entre eux, une pour les assistants qui écrivent du texte, une pour ceux qui agissent seuls, et une vingtaine d’autres. Elles portent toutes le même nom de famille, « Top 10 », et c’est la source de beaucoup de malentendus.

Chaque liste sert à donner des noms communs. Quand deux équipes parlent du même défaut avec les mêmes mots, elles peuvent le compter, le suivre et vérifier qu’il a été corrigé. Une liste ne dit pas comment réparer, et elle ne prouve pas qu’un logiciel est sûr. Elle dit seulement ce qu’il faut chercher en premier, d’après ce que d’autres équipes ont constaté ailleurs.

Les listes sont numérotées, et les numéros changent d’une version à l’autre. Un même code peut donc désigner deux problèmes différents selon l’année. Il faut toujours écrire l’année à côté du numéro, sinon la référence ne veut plus rien dire au bout de quelques mois.

Toutes ces listes ne sont pas entretenues avec le même soin. Certaines sont révisées à partir de mesures faites sur des millions de logiciels, d’autres sont encore marquées comme des brouillons, parfois depuis plusieurs années. Avant de s’appuyer sur l’une d’elles dans un contrat, il faut regarder trois choses : le niveau que l’association donne au projet, la façon dont la liste a été construite, et la date de sa dernière modification.

Pages voisines

Les Top 10 de l'OWASP : une trentaine de listes, un seul nom

Elle cite

: les deux pages se citent l’une l’autre.