OWASP Top 10 2025 : attaques sur la supply chain, erreurs de configuration du cloud et liste des vulnérabilités qui ne change pas
L’OWASP Top 10 est l’équivalent, pour la sécurité applicative, d’un bilan de santé. Tous les trois à quatre ans, l’Open Worldwide Application Security Project collecte des données réelles sur les vulnérabilités auprès d’organismes de test et de fournisseurs de sécurité, les combine à une enquête communautaire auprès de professionnels, puis publie une liste classée des principaux risques de sécurité des applications web.
L’édition 2025 est arrivée. Basée sur l’analyse de plus de 175 000 enregistrements CVE couvrant près de 2,8 millions d’applications, ainsi que sur une enquête menée auprès de 221 experts en sécurité, elle révèle un paysage qui a évolué sur certains points majeurs — et sur d’autres, n’a quasiment pas changé.
Les défaillances de la supply chain logicielle font leur entrée à la troisième place. La mauvaise configuration de la sécurité passe de la cinquième à la deuxième position. La mauvaise gestion des conditions exceptionnelles arrive en dixième position. Les risques liés au code généré par l’IA figurent dans une section « prochaines étapes ». Et le contrôle d’accès défaillant reste numéro un — pour la 22e année consécutive.
Cinq enseignements clés
- Le contrôle d’accès défaillant occupe la première place depuis 2003. Ce risque reste en tête de l’OWASP Top 10 depuis la première publication il y a plus de vingt ans. En moyenne, 3,73 % des applications testées présentaient une ou plusieurs des 40 failles CWE associées à cette catégorie. Les organisations continuent de créer des mécanismes de contrôle d’accès personnalisés, sujets à erreurs, testés de façon inégale et truffés de chemins d’escalade de privilèges. Si la vulnérabilité web la plus critique perdure depuis 22 ans, c’est un problème structurel du secteur — pas un simple problème de correctif.
- Les défaillances de la supply chain logicielle font leur entrée à la troisième place. Le plus grand changement structurel est l’arrivée de cette catégorie à la troisième position. Elle remplace et élargit l’ancienne catégorie « Composants vulnérables et obsolètes » pour couvrir les attaques sur l’ensemble de la supply chain logicielle : bibliothèques open source compromises, mécanismes de mise à jour des fournisseurs piratés, pipelines CI/CD altérés, attaques directes sur les postes de développement. Comme l’explique Tanya Janca, autrice principale OWASP : « Les développeurs sont désormais une cible privilégiée pour de nombreuses attaques en ligne. »
- La mauvaise configuration de la sécurité grimpe de la cinquième à la deuxième place. L’adoption du cloud a rendu la mauvaise configuration omniprésente et catastrophique. Identifiants par défaut non modifiés, buckets de stockage cloud accessibles publiquement, fonctions inutiles laissées activées : tout cela est courant. Toutes les applications testées dans les données présentaient une forme de mauvaise configuration. Ce n’est pas un risque marginal. Il concerne quasiment tout le monde.
- Les risques liés au code généré par l’IA entrent dans le radar de l’OWASP. L’IA n’a pas intégré le top 10, mais figure dans la section « prochaines étapes ». Intitulée « Confiance inappropriée dans le code généré par l’IA » — le problème du « vibe coding » — cette catégorie reconnaît que les développeurs livrent du code généré par IA sans l’avoir entièrement relu. La tendance est claire : les risques liés au code généré par l’IA sont sur la voie d’une future intégration.
- Deux nouvelles catégories reflètent un recentrage sur les causes profondes. L’édition 2025 introduit les défaillances de la supply chain logicielle à la troisième place et la mauvaise gestion des conditions exceptionnelles à la dixième. Les failles SSRF ont été intégrées au contrôle d’accès défaillant. Ces changements montrent la volonté de l’OWASP d’identifier les causes profondes plutôt que les symptômes — et de rappeler qu’un logiciel sécurisé doit aussi savoir échouer en toute sécurité.
Contrôle d’accès défaillant : 22 ans à la première place
Le contrôle d’accès défaillant est la vulnérabilité qui refuse de disparaître. Elle regroupe désormais 40 failles CWE — un record — et couvre l’escalade de privilèges, les références directes non sécurisées à des objets, les erreurs de configuration CORS et la manipulation de jetons. Les SSRF ont également été intégrés, car beaucoup de ces failles relèvent fondamentalement du contrôle d’accès.
Jeff Williams, créateur du premier OWASP Top 10, explique cette persistance : « Tout le monde essaie de concevoir ses propres mécanismes d’authentification et de contrôle d’accès. » Une application web typique peut comporter une centaine de points d’accès pour une vingtaine de rôles différents. « La plupart des gens analysent leur application en pensant à un seul rôle », indique Williams. « C’est très difficile à vérifier. »
La conclusion est inconfortable : ce n’est pas un problème que le secteur est en train de résoudre. Les organisations qui s’appuient sur des mécanismes de contrôle d’accès personnalisés héritent d’un risque qui persiste depuis vingt ans, car elles continuent à tout reconstruire au lieu d’adopter des frameworks éprouvés comme RBAC et ABAC.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le vérifier ?
Pour en savoir plus :
La mauvaise configuration de la sécurité grimpe à la deuxième place
La mauvaise configuration de la sécurité passe de la cinquième à la deuxième place, car l’adoption du cloud a rendu les systèmes bien plus configurables — et plus il y a de paramètres, plus on risque de se tromper.
Cette catégorie regroupe les identifiants par défaut non modifiés, les fonctions inutiles laissées activées, les messages d’erreur trop détaillés révélant l’architecture du système, et les buckets de stockage cloud accessibles publiquement. Il ne s’agit pas de vecteurs d’attaque sophistiqués, mais d’oublis de configuration qui donnent littéralement les clés aux attaquants.
À mesure que les environnements cloud deviennent plus complexes — multipliant fournisseurs, régions et services — la surface d’exposition liée à la mauvaise configuration s’étend. Les organisations doivent considérer la configuration comme une discipline de sécurité : paramètres sécurisés par défaut, validation automatisée et changement forcé des identifiants doivent devenir la norme.
Les défaillances de la supply chain logicielle font leur entrée à la troisième place
C’est le changement structurel le plus marquant de la liste 2025. Les défaillances de la supply chain logicielle remplacent la catégorie plus restreinte « Composants vulnérables et obsolètes » et élargissent le périmètre à l’ensemble de la chaîne de construction, de distribution et de mise à jour.
Tanya Janca décrit ce changement : « Ce n’est plus seulement un problème d’inclusion d’une bibliothèque avec une dépendance douteuse. » Désormais, les attaques visent l’IDE, le pipeline CI/CD, les plugins, les dépôts et les postes de développement. « Toute la supply chain logicielle est aujourd’hui dans le viseur des attaquants. »
Cinquante pour cent des experts interrogés placent le risque supply chain en tête de leurs préoccupations — c’est le consensus le plus fort de toutes les catégories. Pour s’en protéger, il faut des nomenclatures logicielles (SBOM), la signature de code, des environnements de build durcis, l’analyse de vulnérabilités des dépendances transitives et des mécanismes de mise à jour sécurisés avec vérification d’intégrité.
Ce qui a changé — et ce qui est nouveau
Les défaillances cryptographiques (quatrième place) passent de la deuxième à la quatrième position — non parce que les problèmes de chiffrement sont moins fréquents, mais parce que d’autres risques progressent plus vite. La transmission de données sensibles en clair, les algorithmes faibles et la validation insuffisante des certificats restent très répandus. Le chiffrement validé FIPS et TLS 1.3 constituent le socle actuel des bonnes pratiques.
L’injection (cinquième place) poursuit sa lente régression. Les frameworks modernes avec requêtes paramétrées et encodage des sorties ont permis de réduire l’incidence, mais le risque n’a pas disparu.
La conception non sécurisée (sixième place) recule légèrement, signe d’une amélioration de la modélisation des menaces dans le secteur. Cette catégorie rappelle que la sécurité ajoutée après coup ne peut pas corriger un système qui n’a jamais été conçu pour être sûr.
Les défaillances d’authentification (septième place) couvrent le brute force, les mots de passe faibles, les identifiants de session exposés et l’absence de MFA. À l’ère du phishing dopé à l’IA, ne pas activer l’authentification multifactorielle pour les fonctions sensibles devient une faille difficilement justifiable.
Les défaillances d’intégrité logicielle ou des données (huitième place) concernent la confiance sans vérification — mises à jour non signées, plugins non validés, pipelines CI/CD acceptant des artefacts sans contrôle d’intégrité.
Les défaillances de journalisation et d’alerte de sécurité (neuvième place) conservent leur rang avec une évolution majeure : « alerte » a été ajouté explicitement au nom de la catégorie. L’OWASP envoie un message clair : journaliser sans alerter n’apporte que peu de valeur. Les organisations doivent associer journaux d’audit, alertes en temps réel et intégration SIEM pour transformer la collecte de données en détection exploitable.
Mauvaise gestion des conditions exceptionnelles (dixième place) : c’est une nouveauté. Elle couvre les erreurs de gestion des exceptions et des cas limites qui entraînent des fuites d’informations ou des contournements de sécurité. Brian Glas, responsable du projet OWASP, note que ce risque frôlait le top 10 depuis des années. « Si le classement était purement basé sur les données, nous n’aurions pas une liste pertinente, car elle ne regarderait que le passé. »
L’alerte « vibe coding »
L’IA n’a pas intégré le top 10. Mais la mention dédiée de l’OWASP dans la section « prochaines étapes » — « Confiance inappropriée dans le code généré par l’IA » — doit être prise au sérieux.
Tanya Janca est claire : « Même si nous n’avons pas de données prouvant que le code généré par l’IA crée plus de risques que le code écrit par un humain, grâce aux retours de la communauté, à l’expérience professionnelle et au partage constant d’exemples en ligne, nous avons jugé utile d’ajouter une section. »
Son conseil : lisez et comprenez parfaitement le code généré par l’IA avant de l’intégrer. Si l’adoption de la génération de code par IA continue de s’accélérer, cette catégorie rejoindra probablement le top 10 dans une prochaine édition. Les organisations qui mettent en place des revues de code IA dès maintenant prendront une longueur d’avance.
Kiteworks : une sécurité conçue pour les vulnérabilités persistantes
L’OWASP Top 10 met en lumière un constat récurrent : la plupart des applications web privilégient la fonctionnalité, la sécurité passant au second plan. Kiteworks répond à cette problématique dès la conception.
Pour le contrôle d’accès défaillant, Kiteworks propose une vérification zéro trust à chaque requête, des contrôles d’accès basés sur les rôles et les attributs, l’application du principe du moindre privilège par défaut, et des journaux d’audit complets. Contrairement aux applications qui développent leur propre contrôle d’accès, Kiteworks fournit des contrôles préconçus et testés pour les communications de données sensibles — éliminant ainsi la principale vulnérabilité OWASP par l’architecture.
Pour les défaillances de la supply chain, Kiteworks applique un SDLC durci avec pipelines CI/CD isolés, signature de code, SBOM et analyse continue des vulnérabilités — et gère les échanges de données avec les tiers via des autorisations limitées dans le temps et le périmètre.
Pour la mauvaise configuration, la plateforme est sécurisée par défaut, avec validation automatisée et changement forcé des identifiants. Pour les défaillances cryptographiques, elle fournit un chiffrement validé FIPS 140-3 et TLS 1.3. Pour l’authentification, elle impose la MFA, des politiques de mots de passe robustes et le SSO d’entreprise. Pour la journalisation, elle offre des journaux d’audit inviolables avec intégration SIEM, alertes en temps réel et reporting conformité préconfiguré pour le RGPD, HIPAA, CMMC et d’autres référentiels.
Les plateformes de partage de fichiers grand public exposent des liens partagés qui contournent les contrôles d’accès et offrent une traçabilité limitée. Les plateformes de messagerie restent vulnérables au transfert qui échappe à la gouvernance et au phishing dopé à l’IA. Les solutions MFT historiques présentent des configurations complexes qui augmentent le risque de mauvaise configuration. Kiteworks propose une architecture sécurisée par conception, exactement ce que l’OWASP Top 10 réclame au secteur depuis 22 ans.
Pour découvrir comment Kiteworks peut vous aider, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
L’OWASP Top 10 2025 identifie le contrôle d’accès défaillant comme la vulnérabilité web la plus critique — une position qu’il occupe depuis 2003. La mauvaise configuration de la sécurité grimpe à la deuxième place, et les défaillances de la supply chain logicielle font leur entrée à la troisième. Ensemble, ces trois catégories expliquent la majorité des violations réelles. Les organisations qui n’adoptent pas des contrôles d’accès conçus pour la sécurité et des configurations sécurisées par défaut restent exposées aux mêmes risques qui dominent la liste depuis vingt ans.
Les attaques sur la supply chain logicielle visent le processus de construction, de distribution ou de mise à jour, plutôt que les applications elles-mêmes. Les attaquants injectent du code malveillant dans des bibliothèques open source, manipulent les pipelines CI/CD ou compromettent les postes de développement. Cinquante pour cent des experts en sécurité classent désormais le risque supply chain en tête de leurs préoccupations. Pour s’en protéger, il faut des nomenclatures logicielles (SBOM), la signature de code, des environnements de build durcis et une gestion rigoureuse des risques tiers pour chaque dépendance — pas seulement les dépendances directes.
La mauvaise configuration de la sécurité apparaît dans quasiment toutes les applications testées, car l’adoption du cloud a rendu les systèmes bien plus configurables — et multiplié les occasions de mal configurer. Identifiants par défaut non modifiés, buckets de stockage publics, messages d’erreur détaillés révélant l’architecture système : ces éléments sont souvent en cause. Le problème s’aggrave à mesure que les organisations utilisent plusieurs fournisseurs cloud et des environnements Infrastructure-as-Code. Des paramètres sécurisés par défaut et la validation automatisée des configurations sont les seules protections à l’échelle de cette complexité.
La section « prochaines étapes » de l’OWASP 2025 signale la « confiance inappropriée dans le code généré par l’IA » — le problème du « vibe coding » — comme un risque émergent qui pourrait intégrer le top 10. Les développeurs valident du code généré par IA sans l’avoir entièrement relu, introduisant ainsi des vulnérabilités que les scanners automatisés ne détectent pas, car aucun humain n’a compris la logique. La solution est simple : traitez le code généré par l’IA comme une entrée non fiable. Lisez-le, comprenez-le et testez-le avant de le livrer. Les journaux d’audit retraçant la provenance du code deviendront de plus en plus importants à mesure que ce risque se développe.
La cartographie des contrôles de sécurité avec l’OWASP Top 10 commence par les trois premiers : appliquez le principe du moindre privilège avec des frameworks éprouvés plutôt que des solutions maison, validez les configurations selon des standards sécurisés par défaut, et recensez chaque dépendance tierce dans votre pipeline de build. Pour les défaillances cryptographiques, standardisez le chiffrement validé FIPS et TLS 1.3. Imposer la MFA sur tous les flux d’authentification. Enfin, comblez le manque de journalisation en associant journaux d’audit, alertes en temps réel et intégration SIEM — journaliser sans alerter n’est pas une capacité de détection.
Ressources complémentaires
- Article de blog Architecture Zero Trust : ne jamais faire confiance, toujours vérifier
- Vidéo Microsoft GCC High : les inconvénients qui poussent les sous-traitants de la défense vers de meilleures solutions
- Article de blog Sécuriser les données classifiées après détection par DSPM
- Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
- Vidéo Guide ultime pour sécuriser le stockage des données sensibles à destination des responsables IT