OWASP Top 10 2025 : les 10 risques web, et ce que les failles exploitées
en disent

Si la cybersécurité web avait un best-of, ce serait l'OWASP Top 10. C'est la liste de référence : les dix catégories de failles les plus critiques des applications web, compilées par la communauté OWASP à partir de montagnes de données réelles. Développeurs, pentesters, RSSI, auditeurs ISO 27001 : tout le monde y revient. C'est un peu le "permis de conduire" de l'AppSec.

Une nouvelle édition est sortie. Publiée par l'OWASP en 2025, l'OWASP Top 10 2025 remplace la version 2021 qui régnait depuis quatre ans. Et ça bouge : deux nouvelles catégories, des renommages, et le SSRF qui se fait carrément absorber. Si vous étiez resté sur le classement 2021, c'est le moment de mettre à jour vos slides.

Nous avons aussi fait ce que le classement ne fait pas : confronter ses dix catégories aux failles réellement exploitées. Sur les 1 410 failles du catalogue KEV de la CISA publiées depuis 2015, l'intégrité logicielle (A08) pèse 2,82 fois plus que dans l'ensemble des CVE, le numéro un Broken Access Control moins (17,2 % contre 22,7 %), et un tiers des failles exploitées n'entre dans aucune catégorie. Le détail est plus bas, catégorie par catégorie.

Ce qui change entre 2021 et 2025

La méthodologie 2025 s'appuie sur du lourd : près de 220 000 CVE extraites pour noter l'exploitabilité et l'impact, 589 CWE présentes dans les données, plus de 2,8 millions d'applications testées, le tout croisé avec une enquête auprès des praticiens. Résultat, trois mouvements à retenir :

• Deux nouvelles catégories : Software Supply Chain Failures (A03, l'ancienne catégorie "composants vulnérables" élargie à toute la chaîne d'approvisionnement) et Mishandling of Exceptional Conditions (A10, totalement inédite).
• SSRF a disparu de la liste en tant que catégorie autonome : il a été fusionné dans le Broken Access Control (A01). Le numéro 1 ne fait que grossir.
• Security Misconfiguration grimpe de la 5e à la 2e place. Avec le tout-cloud et le tout-config-as-code, mal régler ses services coûte cher.

Le Top 10 face aux failles exploitées : A08 pèse 2,8 fois plus, A01 moins

L'OWASP construit son classement surtout à partir de résultats de tests applicatifs : la part des applications testées où une faiblesse a été trouvée au moins une fois, pondérée par des scores d'exploitabilité et d'impact. Huit catégories sur dix en sortent, les deux autres viennent d'une enquête auprès des praticiens. C'est une mesure de fréquence chez les défenseurs. Nous avons voulu regarder l'autre bout de la chaîne, ce que les attaquants exploitent réellement. Chaque catégorie de l'édition 2025 publie la liste officielle de ses CWE ; nous l'avons appliquée telle quelle à toutes les CVE publiées dans la NVD depuis 2015, puis aux failles du catalogue CISA KEV, celles dont l'exploitation est confirmée.

Trois choses sautent aux yeux. Le numéro un, Broken Access Control, pèse 22,7 % des CVE dotées d'une CWE, mais 17,2 % seulement des failles du KEV. À l'inverse, deux catégories du milieu de classement y sont nettement sur-représentées : l'authentification (A07) et l'intégrité logicielle et des données (A08), portée par la désérialisation. Enfin, un tiers des failles exploitées (475 sur 1 410, soit 33,7 %) n'ont aucune CWE de la liste, contre 28,4 % dans la NVD. Le rapport entre les deux parts donne une lecture directe : au-dessus de 1, la catégorie pèse plus lourd chez les attaquants que dans le volume des CVE.

Ce graphique ne dit pas que le contrôle d'accès est un faux problème, et l'encadré plus bas explique pourquoi. Il dit que le Top 10 décrit les applications web, alors que le catalogue KEV recense des produits : la première CWE du KEV est l'écriture hors limites (CWE-787, 10,3 % des failles, contre 5,18 % dans la NVD), une faiblesse de code natif qu'aucune catégorie du Top 10 ne liste, et la confusion de type (CWE-843) y est 9 fois plus fréquente que dans la NVD. Navigateurs, systèmes d'exploitation et équipements réseau occupent une bonne part du catalogue.

La mesure, et ce qu'elle ne dit pas

Les données sont ouvertes : un miroir public des flux de la NVD (instantané au 5 octobre 2026, CVE rejetées exclues) et le catalogue KEV dans sa version 2026.10.04, dont les 1 734 entrées se retrouvent toutes dans la NVD. Les listes de CWE viennent des pages officielles du dépôt de l'OWASP, téléchargées le 7 octobre. Pour chaque CVE, nous retenons la CWE attribuée par la NVD, et à défaut celle de l'autorité qui a déclaré la CVE. Les CVE sans CWE exploitable (9,8 % de la NVD, 10,9 % du KEV) sont exclues des deux côtés. La correspondance est exacte, sans remonter la hiérarchie des CWE. Une contre-expertise a rejoué le calcul depuis les fichiers bruts avec un code écrit séparément et retrouve les mêmes comptages. Changer la règle d'attribution des CWE (celle du déclarant d'abord, ou l'union des deux sources), ou compter en fraction les CVE à plusieurs CWE, déplace les rapports cités de 0,11 au plus, sauf celui de la confusion de type, qui varie de 9,3 à 9,9.

La suite reprend la liste 2025 dans l'ordre. Pour chaque risque : c'est quoi, un exemple concret, et comment s'en prémunir.

A01:2025, Broken Access Control

Le boss final, encore et toujours numéro 1. Le contrôle d'accès, c'est la règle qui empêche un utilisateur d'agir au-delà de ses droits. Quand il est cassé, n'importe qui peut lire, modifier ou supprimer des données qui ne lui appartiennent pas, ou déclencher des actions réservées aux admins. Depuis 2025, le SSRF (forcer le serveur à émettre des requêtes vers des cibles internes) entre aussi dans cette famille. Le CSRF, qui fait exécuter une action à un utilisateur légitime à son insu, y est rangé depuis l'édition 2021 : c'est le jeton CSRF qui l'empêche, quand il est vérifié.

Exemple concret : l'IDOR (Insecure Direct Object Reference). Vous consultez votre facture à l'URL /api/invoices/1042. Vous changez 1042 en 1043... et vous tombez sur la facture du client d'à côté. Pas d'exploit sophistiqué, juste un compteur incrémenté. Sur une API, la même faille porte un autre nom, le BOLA, et elle est en tête de l'OWASP API Security Top 10.

La parade : "deny by default" (tout est interdit sauf autorisation explicite), vérification des droits côté serveur pour chaque ressource (jamais en se fiant à l'UI), et identifiants d'objets non devinables. Pour le SSRF : valider/allowlister les URL sortantes et segmenter le réseau.

Dans les failles exploitées : 17,2 % du catalogue KEV, contre 22,7 % des CVE. L'IDOR (CWE-639) illustre bien l'écart : 2 856 CVE, une seule entrée au KEV. Ce n'est pas une faille rare, c'est une faille d'application sur mesure, que le catalogue ne voit pas. La catégorie contient aussi des faiblesses qui pèsent plus lourd chez les attaquants : la traversée de répertoire (CWE-22), rangée dans A01, représente 6,5 % du KEV contre 3,04 % des CVE, et le SSRF, arrivé ici en 2025, 1,7 % contre 1,32 %.

A02:2025, Security Misconfiguration

La nouvelle vedette. Promue de la 5e à la 2e place, la mauvaise configuration regroupe tout ce qui est mal réglé : services avec leurs paramètres par défaut, comptes admin/admin jamais changés, buckets cloud en accès public, en-têtes de sécurité absents, messages d'erreur trop bavards, ports de debug ouverts en prod.

Exemple concret : un bucket S3 laissé en lecture publique "le temps d'un test", qui finit indexé par un moteur de recherche avec, dedans, les exports clients en CSV. Classique, et toujours autant de dégâts.

La parade : durcissement (hardening) systématique, suppression des fonctionnalités et comptes inutiles, configuration en infrastructure-as-code versionnée et auditée, et une revue de config qui suit l'appli de la recette à la prod.

A03:2025, Software Supply Chain Failures

La grande nouveauté. Anciennement "composants vulnérables et obsolètes", cette catégorie a été élargie à toute la chaîne d'approvisionnement logicielle : dépendances open source, registres de paquets, plugins CI/CD, images de conteneurs, scripts tiers. Votre code peut être parfait ; si une de vos 1 200 dépendances est compromise, c'est vous qui tombez.

Exemple concret : un mainteneur de paquet npm se fait pirater, pousse une version vérolée, et des milliers de builds l'installent automatiquement (cf. les attaques de type typosquatting et compromission de mainteneurs qui défraient régulièrement la chronique). Côté applicatif, un plugin tiers vulnérable suffit : on montre comment un plugin WordPress mène à une exécution de code à distance sur WordPress.

La parade : inventaire des dépendances (SBOM), analyse de composition logicielle (SCA), épinglage des versions et vérification des signatures, et un pipeline CI/CD verrouillé (le maillon faible, c'est souvent là).

Dans les failles exploitées : rien à lire, et c'est une information. Les CWE de cette catégorie ne sont presque jamais attribuées à une CVE (60 dans toute la NVD depuis 2015, aucune au KEV). Une compromission de chaîne d'approvisionnement se décrit rarement comme une faiblesse de code : elle échappe aux statistiques par CWE, pas au risque.

A04:2025, Cryptographic Failures

Quand la crypto échoue à protéger les données. On parle de données sensibles transmises en clair, d'algorithmes obsolètes (MD5, SHA-1, DES), de clés codées en dur, de mots de passe stockés sans salage, ou d'une "crypto maison" bricolée.

Exemple concret : une base de mots de passe stockés en MD5 non salé. Une fuite, un coup de rainbow table, et tous les mots de passe courants tombent en quelques minutes.

La parade : TLS partout, algorithmes modernes (AES, ChaCha20, et bcrypt/argon2 pour les mots de passe), gestion des clés via un coffre-fort (KMS/Vault), et surtout : ne jamais rouler sa propre crypto.

A05:2025, Injection

La doyenne du classement. Rétrogradée à la 5e place mais toujours redoutable, l'injection survient quand des données non fiables sont interprétées comme du code/une commande : SQL, NoSQL, commandes OS, LDAP... et le XSS (injection de scripts côté client) entre dans cette famille.

Exemple concret : une requête SQL construite par concaténation. L'attaquant saisit ' OR '1'='1 dans un champ login :

-- Code vulnérable : la saisie est concaténée dans la requête
query = "SELECT * FROM users WHERE name = '" + input + "'"

-- Saisie de l'attaquant :  ' OR '1'='1

-- Requête réellement exécutée, la condition est toujours vraie
-- et la clause de filtrage ne filtre plus rien :
SELECT * FROM users WHERE name = '' OR '1'='1'

La parade : requêtes paramétrées (prepared statements) ou ORM, validation et échappement des entrées, principe du moindre privilège sur le compte de base de données. La règle d'or : ne jamais mélanger code et données. Le cas de l'injection SQL détaille les familles d'attaques et pourquoi les requêtes préparées sont la seule défense qui tient.

Dans les failles exploitées : la catégorie paraît sous-représentée (24,8 % du KEV contre 30,58 % des CVE), mais c'est une moyenne trompeuse. Elle réunit des faiblesses aux destins opposés. Le XSS est la CWE la plus fréquente de toute la NVD (14,78 % des CVE dotées d'une CWE) et ne pèse que 2,0 % du KEV. L'injection de commande système fait le chemin inverse : 2,3 % des CVE, 8,2 % du KEV. Sans le XSS, la catégorie Injection pèse 1,41 fois plus dans le KEV que dans la NVD.

A06:2025, Insecure Design

Le bug qui n'est pas un bug. Ici, la faille n'est pas dans l'implémentation mais dans la conception : une logique métier qui ne prévoit pas l'abus, l'absence de modélisation des menaces, un workflow qui fait confiance à l'utilisateur là où il ne faut pas. Vous pouvez coder parfaitement une mauvaise idée.

Exemple concret : un "mot de passe oublié" basé sur des questions secrètes ("nom de votre animal ?") dont les réponses traînent sur les réseaux sociaux. Le code est nickel, le design est cassé.

La parade : threat modeling dès la conception, patterns sécurisés réutilisables, tests de la logique métier, et un cycle de développement sécurisé (SSDLC) qui intègre la sécurité en amont, pas en rustine finale.

A07:2025, Authentication Failures

Renommée (exit "Identification and..."). Tout ce qui touche à la vérification de l'identité : mots de passe faibles autorisés, absence de MFA, attaques par force brute non limitées, gestion de session bancale (tokens prévisibles, sessions qui n'expirent jamais), credential stuffing.

Exemple concret : un formulaire de connexion sans rate limiting ni MFA. L'attaquant rejoue 50 000 couples email/mot de passe issus d'une fuite précédente ; un certain pourcentage passe, parce que les gens réutilisent leurs mots de passe. C'est la mécanique du credential stuffing.

La parade : MFA généralisée, politiques de mots de passe alignées sur les recommandations modernes (longueur > complexité arbitraire), limitation des tentatives, sessions robustes avec expiration et rotation. Idéalement, déléguer l'auth à un service centralisé et durci plutôt que de la réinventer.

Dans les failles exploitées : 10,3 % du KEV contre 5,55 % des CVE, soit 1,85 fois plus. Ce ne sont pas les mots de passe faibles qui tirent ce chiffre, ce sont deux CWE d'équipements et de logiciels exposés : la fonction critique accessible sans authentification (CWE-306, 3,09 fois plus présente au KEV) et l'authentification contournable (CWE-287, 2,33 fois plus).

A08:2025, Software or Data Integrity Failures

Quand on fait confiance sans vérifier l'intégrité. Mises à jour non signées, désérialisation de données non fiables, pipelines CI/CD qui déploient sans contrôle d'intégrité. Cousine de la supply chain, cette catégorie cible le moment où du code ou des données sont acceptés sans preuve qu'ils n'ont pas été altérés.

Exemple concret : une appli qui télécharge ses mises à jour automatiques depuis un serveur en HTTP sans vérifier de signature. Un attaquant en position d'intercepteur livre sa propre "mise à jour"... et exécute son code sur tous les clients.

La parade : signatures numériques sur les artefacts et mises à jour, vérification des intégrités, désérialisation prudente (éviter les formats dangereux, valider le contenu), et durcissement du pipeline de build.

Dans les failles exploitées : c'est la catégorie la plus sur-représentée de toutes, 6,8 % du KEV contre 2,41 % des CVE (x2,82). La raison tient en une CWE : la désérialisation de données non fiables (CWE-502) passe de 1,16 % des CVE à 5,2 % du KEV, 4,52 fois plus. Une désérialisation exploitable mène souvent à une exécution de code à distance, ce qui en fait une cible de choix.

A09:2025, Security Logging and Alerting Failures

Renommée "Alerting" plutôt que "Monitoring". La nuance compte : il ne suffit pas de journaliser, il faut alerter et réagir. Sans journalisation suffisante ni détection, une intrusion peut durer des mois. Le délai moyen de détection d'une compromission se compte encore en semaines.

Exemple concret : 10 000 tentatives de connexion échouées en une nuit, et... aucune alerte. Personne ne regarde, rien ne remonte. L'attaquant a tout le temps du monde.

La parade : journaliser les évènements de sécurité (auth, accès, erreurs), centraliser (SIEM), définir des alertes actionnables, et tester son plan de réponse à incident. Des logs que personne ne lit ne servent à rien.

A10:2025, Mishandling of Exceptional Conditions

La grande inédite de 2025. Cette catégorie cible la mauvaise gestion des cas exceptionnels et des erreurs : exceptions non gérées, états d'échec laissés dans un mode dégradé non sécurisé ("fail open" au lieu de "fail closed"), logique d'erreur qui révèle trop d'informations ou contourne les contrôles. Bref, ce qui se passe quand ça ne se passe pas comme prévu.

Exemple concret : un middleware d'autorisation qui, en cas d'exception (base injoignable, token mal formé), laisse passer la requête "par sécurité pour ne pas casser le service". Résultat : il suffit de provoquer l'erreur pour court-circuiter le contrôle d'accès.

La parade : "fail closed" par défaut (en cas de doute, on refuse), gestion explicite et homogène des exceptions, messages d'erreur génériques côté utilisateur (détails dans les logs uniquement), et tests des chemins d'échec, pas seulement du "happy path".

Le tableau récap des 10 risques 2025

Comment on teste tout ça (et pourquoi un scan ne suffit pas)

Reste à savoir si votre application y est vulnérable. Un scanner automatisé attrapera une partie des injections et des composants obsolètes, mais sera aveugle sur le Broken Access Control, l'Insecure Design ou la mauvaise gestion des exceptions : ça demande de comprendre la logique métier et de raisonner comme un attaquant. C'est le métier du pentest. Et le Top 10 n'est pas une méthode de test, juste une liste de risques : pour savoir quoi vérifier et comment, l'OWASP publie deux autres référentiels, ASVS et WSTG, que tout pentest sérieux suit d'assez près.

Chez own2pwn, les missions de pentest web blackbox et pentest web whitebox sont cadrées pour couvrir l'intégralité de l'OWASP Top 10, avec exploitation manuelle des failles pour distinguer le vrai du faux positif. Pour comprendre où s'arrête un scanner et où commence le travail humain, notre article pentest vs scan de vulnérabilité fait le tri.

Côté outillage automatisé, le combo SAST / DAST / IAST boosté à l'IA permet de détecter en continu une bonne part de ces risques dès le développement, surtout une fois branché au pipeline, comme on le montre dans intégrer SAST et DAST dans la CI/CD. C'est l'approche de SecAI, notre plateforme AppSec AI-native : l'automatisation balaie le gros du volume, le pentester se concentre sur ce que la machine ne sait pas voir.

À retenir

• La version de référence est désormais l'OWASP Top 10 2025, qui remplace celle de 2021.
• Broken Access Control reste numéro 1 et absorbe le SSRF ; Security Misconfiguration bondit à la 2e place.
• Deux nouvelles catégories : Software Supply Chain Failures (A03) et Mishandling of Exceptional Conditions (A10).
• C'est une liste de sensibilisation : la traiter ne garantit pas la sécurité, c'est le socle minimal.
• Les catégories "logique" (Access Control, Insecure Design, Exceptions) échappent largement aux scanners : le pentest manuel reste indispensable.
• Le classement n'est pas un ordre d'exploitation. Rapportées au catalogue KEV, l'intégrité logicielle (x2,82, portée par la désérialisation) et l'authentification (x1,85) pèsent bien plus lourd que dans le volume des CVE, le XSS beaucoup moins (2,0 % du KEV contre 14,78 % des CVE), et un tiers des failles exploitées sort du Top 10.

Pour la source officielle et le détail de chaque catégorie, direction le site de l'OWASP Top 10 2025 et son introduction méthodologique. Et si vous voulez savoir lesquels de ces dix risques concernent votre application, parlons-en.

Questions fréquentes