- 25/08/2026
OWASP Top 10, deux nouvelles failles à connaître
- Par Maéva MARMIN
- 10 min
- EXPERISE & EDUCATION
Un développeur pousse du code un vendredi après-midi, pressé de partir en week-end. Le lundi suivant, un attaquant manipule un paramètre d'API. Il accède ainsi à des dossiers clients qui ne devraient pas être visibles, puis les exfiltre. Une simple vérification d'autorisation aurait pourtant tout empêché. Ce genre de scénario, l'OWASP Top 10 cherche justement à le prévenir depuis plus de 20 ans. En janvier 2026, la liste a d'ailleurs reçu sa première vraie mise à jour depuis 2021. Deux nouvelles catégories font leur entrée, et le classement s'en trouve largement rebattu.
CWE : Common Weakness Enumeration, une classification standardisée des types de failles logicielles. | CVE : l'identifiant attribué à chaque vulnérabilité publiquement recensée, souvent rattachée à une ou plusieurs CWE. | SSRF : Server-Side Request Forgery, une faille où un serveur est forcé d'effectuer une requête vers une cible choisie par l'attaquant. | BOLA : Broken Object Level Authorization, un défaut de contrôle d'accès très fréquent sur les API. | SDLC : Software Development Life Cycle, l'ensemble du cycle de développement d'un logiciel.
Ce qu'est vraiment l'OWASP Top 10
L'OWASP (Open Web Application Security Project) est une fondation à but non lucratif. Elle documente les risques de sécurité les plus courants dans les applications web. Son Top 10 n'est d'ailleurs pas une norme de conformité au sens strict. C'est plutôt un document de sensibilisation, pensé pour aider les développeurs et les équipes sécurité à prioriser leurs efforts (OWASP).
Cette huitième édition change pourtant plus de choses que les précédentes. L'équipe a en effet analysé les données de plus de 2,8 millions d'applications. Elle a aussi extrait environ 175 000 enregistrements CVE, et cartographié 248 CWE au sein des dix catégories retenues.
Le classement complet, catégorie par catégorie
Huit catégories mesurées, deux catégories votées
Huit des dix catégories proviennent directement des données de test. Les deux dernières sont choisies par vote de la communauté des praticiens. Cela permet de capter des risques réels, mais encore mal couverts par les outils automatisés.
Le classement, position par position
3,73 % des applications testées touchées. Le SSRF y est désormais intégré.
3,00 % des applications touchées. La configuration pèse de plus en plus dans le comportement des applications.
Nouvelle catégorie. Peu présente dans les données, mais les scores d'impact les plus élevés de tout le classement.
3,80 % des applications touchées, souvent à l'origine d'une exposition de données sensibles.
La catégorie la plus testée historiquement, du XSS jusqu'à l'injection SQL.
L'industrie progresse visiblement sur la modélisation des menaces en amont.
Renommée pour mieux refléter ses CWE. Les frameworks standardisés aident à limiter les occurrences.
Vérifier que le code et les artefacts n'ont pas été altérés, à un niveau plus fin que la chaîne d'approvisionnement.
Un bon logging sans alerte reste peu utile. Catégorie choisie par la communauté, sous-représentée dans les tests automatisés.
Nouvelle catégorie. Erreurs mal gérées, échecs logiques, systèmes qui s'ouvrent au lieu de se fermer en cas d'anomalie.
Sources des chiffres et positions, classement officiel OWASP Top 10:2025 (owasp.org).
« Le contrôle d'accès reste en tête depuis des années. Ce n'est pas la faille la plus spectaculaire, c'est simplement celle qu'on continue d'oublier de vérifier. »
Zoom sur les deux nouvelles venues
Ces deux catégories inédites racontent bien où se déplace le risque aujourd'hui, loin du seul code applicatif.
Une extension de l'ancienne catégorie "composants vulnérables et obsolètes". Elle s'élargit à l'ensemble de la chaîne, dépendances tierces, systèmes de build, infrastructure de distribution. Peu d'occurrences mesurées, mais les scores d'impact les plus sévères du classement quand elle frappe.
24 CWE autour de la mauvaise gestion des erreurs et des échecs logiques. Elle couvre aussi les systèmes qui "s'ouvrent" au lieu de bloquer l'accès en cas d'anomalie. Un angle mort classique des revues de code, désormais formalisé.
Comment ce classement est construit
OWASP ne se contente pas de compiler des statistiques brutes. Huit catégories sortent directement des données de test, collectées auprès d'organisations partenaires. Les deux restantes proviennent d'un sondage mené auprès de praticiens de terrain. Cela permet d'intégrer des risques réels, mais encore trop récents pour apparaître massivement dans les outils de scan automatisés.
Ce que ça change concrètement pour vos équipes
Au-delà du classement, l'intérêt du Top 10 tient à son usage quotidien, pas seulement lors d'un audit annuel.
- Utiliser ainsi les 10 catégories comme trame pour vos revues de code, plutôt qu'une liste à cocher ponctuelle.
- Intégrer les CWE pertinentes à vos quality gates dans le pipeline CI/CD, en fonction de votre langage et de votre framework.
- Traiter la chaîne d'approvisionnement logicielle comme un sujet à part entière, pas comme un simple inventaire de dépendances à jour.
- Vérifier aussi que vos systèmes échouent de façon sécurisée (fail closed), pas en laissant l'accès ouvert par défaut en cas d'erreur.
- S'assurer que vos logs de sécurité déclenchent de vraies alertes, pas seulement un enregistrement qui dort dans un fichier.
FAQ – Questions fréquentes
L'OWASP Top 10 est-il une obligation réglementaire ?
Non, mais il est largement pris en référence.
Le NIST et l'équipe MITRE CWE font en effet formellement référence aux catégories de l'OWASP Top 10 dans leurs propres cadres. De nombreux référentiels de conformité s'appuient donc dessus en pratique, sans toujours l'imposer explicitement.
Pourquoi le SSRF a-t-il disparu du classement ?
Il n'a pas disparu, il a été absorbé.
Catégorie autonome en 2021, le SSRF est désormais intégré à A01, Contrôle d'accès défaillant. Les deux partagent en effet la même cause racine, à savoir une vérification d'autorisation insuffisante.
À quelle fréquence l'OWASP Top 10 est-il mis à jour ?
Tous les trois à quatre ans en moyenne.
L'édition précédente datait ainsi de 2021. Celle-ci, présentée en novembre 2025 et finalisée en janvier 2026, constitue donc la première mise à jour majeure depuis quatre ans.
Faut-il tester son application sur les 248 CWE d'un coup ?
Non, mieux vaut prioriser selon votre stack technique.
En effet, toutes les CWE ne s'appliquent pas à tous les langages ou frameworks. Mieux vaut donc sélectionner celles qui concernent réellement votre environnement, puis les intégrer progressivement à vos processus.
Votre application couvre-t-elle vraiment
les 10 risques de l'OWASP ?
Contrôle d'accès, configuration, chaîne d'approvisionnement, gestion des erreurs : ces risques ne se détectent pas en relisant le code une fois. Sæpiens réalise des audits de sécurité applicative et des tests d'intrusion structurés autour des catégories reconnues par l'OWASP, pour identifier vos failles réelles avant qu'un attaquant ne les trouve à votre place.
Votre dernière revue de sécurité applicative date de quand ?
AUDITER MON APPLICATION
