OWASP Top 10 web 2025 : les dix catégories et ce qui a changé

C’est la huitième édition du document le plus cité de la sécurité applicative, et la première depuis 2021. Le Top 10 OWASP des risques applicatifs web, millésimé 2025, a été présenté le 6 novembre 2025 à la conférence OWASP Global AppSec de Washington, puis publié dans sa version définitive au début de 2026. Il classe dix catégories de faiblesses, codées A01 à A10, à partir de données portant sur plus de 2,8 millions d’applications testées. Deux entrées sont nouvelles, une est absorbée par une autre, et l’ensemble glisse des symptômes vers les causes.

→ Lire l’explication complète de la marmotte

Les dix catégories de l’édition 2025

Code	Titre officiel	Traduction
A01:2025	Broken Access Control	Contrôle d’accès défaillant
A02:2025	Security Misconfiguration	Mauvaise configuration de sécurité
A03:2025	Software Supply Chain Failures	Défaillances de la chaîne d’approvisionnement logicielle
A04:2025	Cryptographic Failures	Défaillances cryptographiques
A05:2025	Injection	Injection
A06:2025	Insecure Design	Conception non sécurisée
A07:2025	Authentication Failures	Défaillances d’authentification
A08:2025	Software or Data Integrity Failures	Défaillances d’intégrité du logiciel ou des données
A09:2025	Security Logging and Alerting Failures	Défaillances de journalisation et d’alerte de sécurité
A10:2025	Mishandling of Exceptional Conditions	Mauvais traitement des conditions exceptionnelles

Le rang n’est pas une gravité. C’est une position dans un classement agrégé qui mélange la prévalence mesurée et des scores d’exploitabilité et d’impact technique dérivés des CVE (Common Vulnerabilities and Exposures) rattachées à chaque faiblesse. Il ne connaît ni la valeur des données exposées, ni l’architecture locale.

Ce qui change depuis 2021, et pourquoi c’est l’intérêt de la liste

A03 « Software Supply Chain Failures » est nouvelle. Elle élargit l’ancienne catégorie A06:2021 « Vulnerable and Outdated Components » à tout ce qui se compromet dans l’écosystème des dépendances : systèmes de construction, infrastructure de distribution, environnements de développement et leurs extensions, dépôts d’images et d’artefacts. Le détail statistique mérite d’être lu deux fois : c’est la catégorie qui compte le moins d’occurrences dans les données et les scores moyens d’exploitabilité et d’impact les plus élevés des dix. Les auteurs attribuent la rareté apparente à une difficulté de test, pas à une rareté réelle, et la communauté l’a massivement votée comme préoccupation de tête. Le site traite le fond dans l’inventaire de ce qui tourne vraiment, les niveaux SLSA et les dépendances transitives.

A10 « Mishandling of Exceptional Conditions » est nouvelle aussi, et c’est la plus intéressante conceptuellement. Vingt-quatre faiblesses y sont regroupées autour d’une même idée : ce qui se passe quand le programme rencontre une situation qu’il n’avait pas prévue. Message d’erreur qui révèle une information sensible, paramètre manquant non traité, privilège insuffisant mal géré, déréférencement de pointeur nul, et surtout CWE-636, Not Failing Securely, autrement dit l’échec qui ouvre au lieu de fermer. Ces faiblesses étaient auparavant classées sous un libellé de qualité de code, jugé trop vague. Le nouveau découpage est plus utile : un contrôle d’accès qui s’évanouit quand le service d’autorisation ne répond pas n’est pas un défaut de propreté, c’est une porte.

Le SSRF disparaît comme catégorie et rejoint A01. La falsification de requête côté serveur (Server-Side Request Forgery), qui occupait la dixième place en 2021 après un vote de la communauté, est désormais traitée comme une défaillance de contrôle d’accès : le serveur atteint une ressource qu’il ne devrait pas atteindre. C’est logique sur le plan de la cause, et désagréable sur le plan du suivi, puisque les tableaux de bord qui comptaient « A10 » depuis quatre ans comptent maintenant autre chose. Le mécanisme est décrit dans SSRF et désérialisation.

A02 « Security Misconfiguration » monte de la cinquième à la deuxième place. Trois pour cent des applications testées portent au moins une des seize faiblesses de la catégorie. L’explication donnée par les auteurs est sobre : la part du comportement d’une application qui dépend d’une configuration plutôt que d’un code n’arrête pas de croître. Déplacer une décision de sécurité d’un fichier source vers une variable d’environnement ne la rend pas plus sûre, seulement plus facile à changer — par n’importe qui.

A04, A05 et A06 reculent de deux places. Les défaillances cryptographiques passent de la deuxième à la quatrième place (3,80 % des applications, trente-deux faiblesses), l’injection de la troisième à la cinquième (trente-huit faiblesses, et le plus grand nombre de CVE rattachées des dix catégories), la conception non sécurisée de la quatrième à la sixième. Ce recul n’est pas une amélioration de ces trois sujets : c’est l’effet mécanique de la montée de A02 et de l’arrivée de A03. Pour la conception non sécurisée, les auteurs notent cependant un vrai progrès du secteur sur la modélisation de menace, ce que le site aborde dans le threat modeling en amont du développement.

A07 et A09 changent de nom sans changer de rang. « Identification and Authentication Failures » devient « Authentication Failures », pour coller aux trente-six faiblesses réellement rangées là. « Security Logging and Monitoring Failures » devient « Security Logging and Alerting Failures », et la nuance est le point : une journalisation excellente sans alerte n’a presque aucune valeur pour identifier un incident. C’est aussi une catégorie que les données sous-représenteront toujours — on ne détecte pas automatiquement l’absence de détection — et elle a donc été repêchée par le sondage, comme en 2021.

A01 reste premier, avec quarante faiblesses et 3,73 % des applications testées concernées. Le contrôle d’accès défaillant garde sa place non par tradition mais parce qu’il est à la fois le plus répandu et le plus testé. Les deux chemins à vérifier restent les mêmes : horizontal, entre deux comptes de même rôle, et vertical, vers un rôle plus privilégié. Le cas des interfaces de programmation est traité à part, la granularité y étant différente.

Comment la liste est construite, et ce que la méthode ne peut pas voir

Huit catégories sur dix sortent des données. Les deux autres sont promues par un sondage auprès des praticiens. Ce choix est assumé et expliqué : les données ne contiennent que ce que l’industrie sait tester automatiquement à grande échelle, et il faut des années pour qu’une méthode de test nouvelle se répande dans les outils puis produise des chiffres. Regarder les données seules, écrivent-ils, c’est regarder le passé.

Le changement de méthode de cette édition compte pour quiconque compare les chiffres. En 2021, les contributeurs de données étaient contraints sur une liste de faiblesses ; cette fois, aucune restriction. On passe d’environ trente faiblesses analysées en 2017 à près de quatre cents en 2021, puis à 589 dans le jeu de données de 2025, dont 248 se retrouvent effectivement dans les dix catégories. Une limite de quarante faiblesses par catégorie a été posée arbitrairement, sans quoi A01 aurait continué de grossir.

La métrique retenue est la prévalence, pas la fréquence : on compte le nombre d’applications dans lesquelles une faiblesse apparaît au moins une fois, pas le nombre d’occurrences. Le choix évite un biais massif, puisqu’un testeur humain signale une faiblesse une fois quand un outil automatisé en signale chaque instance.

Pour l’exploitabilité et l’impact, les auteurs se sont rabattus sur les scores CVSS (Common Vulnerability Scoring System) version 2 et 3 des CVE rattachées aux faiblesses — environ 175 000 enregistrements, 643 faiblesses distinctes. La version 4 du CVSS a été écartée explicitement : son algorithme ayant été refondu, elle ne fournit plus séparément un score d’exploitation et un score d’impact. Devoir se replier sur une version antérieure d’un système de notation pour pouvoir noter quelque chose est un moment assez représentatif de la gestion des vulnérabilités en général.

Ce que la méthode ne voit pas reste considérable : la logique métier, la fraude, l’abus de fonction légitime, la disponibilité. Une application peut traiter ses dix catégories et autoriser un remboursement frauduleux parce que la règle commerciale le prévoit. Le logiciel n’a pas besoin d’une injection pour prendre une mauvaise décision.

Des symptômes vers les causes

Le fil conducteur revendiqué de cette édition est le passage du symptôme à la cause racine. Les faiblesses sont des deux sortes : « exposition de données sensibles » et « déni de service » décrivent ce qu’on observe, « défaillance cryptographique » et « mauvaise configuration » décrivent pourquoi. Les éditions précédentes mélangeaient les deux ; celle-ci privilégie délibérément la cause, au motif qu’une cause se corrige et qu’un symptôme se constate.

La conséquence pratique est agréable. Une catégorie orientée cause se traduit directement en exigence de conception : une décision d’autorisation centralisée côté serveur pour A01, une configuration durcie par défaut pour A02, un inventaire logiciel et une provenance vérifiée pour A03, des clés séparées des données pour A04, des requêtes paramétrées pour A05. Une catégorie orientée symptôme, elle, ne se traduit qu’en souhait.

Le revers, les auteurs le reconnaissent, est le recouvrement. Avec dix catégories pour 248 faiblesses, il est impossible d’éviter que A02, A03 et A08 se marchent sur les pieds : une mauvaise configuration du système de construction est à la fois une mauvaise configuration, une défaillance de chaîne d’approvisionnement et une défaillance d’intégrité. Pour un ticket, le rattachement exact importe peu ; pour une métrique comparée dans le temps, il importe beaucoup.

Le Top 10 reste par ailleurs une liste de risques, pas un référentiel d’exigences. Pour transformer A01 à A10 en contrôles vérifiables avec une preuve par exigence, le document à ouvrir est l’ASVS (Application Security Verification Standard), dont la version 5.0.0 existe aussi en traduction française. La distinction est traitée dans la page chapeau des Top 10 de l’OWASP et dans la page de l’organisme.

Du code de catégorie au triage réel

Une alerte d’outil rattachée à « A05:2025 » n’est pas une injection : c’est une hypothèse d’injection avec une étiquette. Le passage du code à la décision suppose une preuve reproductible, un prérequis d’attaquant connu et une propriété atteinte identifiée — la démarche est détaillée dans comment lire un rapport OWASP Top 10.

Deux pièges propres à cette édition méritent d’être signalés aux équipes qui suivent des indicateurs. Le premier est la comparaison entre éditions : un graphique qui montre « A03 en baisse depuis 2021 » compare l’injection à la chaîne d’approvisionnement, ce qui ne veut rien dire. Le second est la cartographie des outils : un scanner configuré en 2022 étiquette toujours ses résultats selon la taxonomie 2021, souvent sans le dire, et les deux étiquetages cohabitent dans le même tableau de bord pendant des mois. Noter la version de la taxonomie à côté de celle du moteur suffit à éviter la confusion.

🐝 Ce qui arrive si on s’en passe

Sans l’édition écrite à côté du code, un indicateur « A03 » mélange deux catégories qui n’ont rien en commun, et la courbe affichée en comité de pilotage décrit un progrès qui n’existe pas. Sans la nouvelle catégorie A03, la chaîne d’approvisionnement reste hors du périmètre testé : systèmes de construction, extensions d’environnement de développement et dépôts d’artefacts ne sont pas inventoriés, et la compromission d’un maillon arrive sans qu’aucun compteur bouge — c’est précisément la catégorie aux scores d’exploitation et d’impact les plus élevés. Sans A10, un service qui s’ouvre quand son contrôle d’autorisation ne répond plus continue de passer pour un défaut de robustesse plutôt que pour une porte, et la panne du composant d’autorisation devient un contournement silencieux. Sans la distinction entre liste de risques et référentiel d’exigences, les dix catégories se cochent sans preuve, aucune vérification n’est reproductible, et une régression de configuration retirant un en-tête ou réouvrant une route n’est détectée qu’au prochain audit manuel.

🦫 Explication de la marmotte 🍫

Une association internationale de spécialistes publie tous les quatre ans environ une liste des dix familles de défauts les plus préoccupantes dans les sites et applications web. La version actuelle date de 2025. Elle a été établie en examinant des mesures faites sur plus de deux millions huit cent mille applications, puis en demandant à des professionnels ce que les mesures ne montraient pas encore.

Les grandes familles sont les suivantes : laisser une personne accéder à ce qui ne lui appartient pas, mal régler un logiciel, se faire livrer un composant modifié par un attaquant, protéger les données avec une mauvaise méthode, laisser une commande malveillante se glisser dans un formulaire, concevoir un service dangereux dès le départ, mal vérifier qui se connecte, ne pas vérifier qu’une donnée est bien celle qu’on attend, ne pas enregistrer ni signaler les événements importants, et mal réagir quand une situation imprévue se présente.

Deux familles sont nouvelles : celle qui concerne la fabrication et la livraison des logiciels, et celle qui concerne les situations imprévues. Une famille a disparu en tant que telle : une attaque où un serveur va chercher une ressource qu’il ne devrait pas atteindre est désormais comptée avec les problèmes d’accès.

Les numéros changent d’une version à l’autre, et un même numéro ne désigne pas le même problème selon l’année : il faut donc toujours écrire l’année avec le numéro. Cette liste indique ce qu’il faut chercher ; elle ne prouve pas qu’un logiciel est sûr, et elle ne couvre pas les erreurs de règles commerciales, qui n’ont besoin d’aucun défaut technique pour coûter cher.

Pages voisines

La citent

OWASP Top 10 web 2025 : les dix catégories et ce qui a changé

Elle cite

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

OWASP Top 10 web 2025 : les dix catégories et ce qui a changé

OWASP Top 10 web 2025 : les dix catégories et ce qui a changé

Les dix catégories de l’édition 2025

Ce qui change depuis 2021, et pourquoi c’est l’intérêt de la liste

Comment la liste est construite, et ce que la méthode ne peut pas voir

Des symptômes vers les causes

Du code de catégorie au triage réel

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines