L’OWASP a publié l’édition 2025 de son Top 10 des risques applicatifs web. Nous l’avons lue au complet, méthodologie comprise, et le constat est net : il ne s’agit pas d’un rafraîchissement, mais du remaniement le plus important depuis 2021.
Cet article s’adresse en particulier aux organisations qui ne développent pas elles-mêmes leurs applications. Dans le secteur public québécois, en agroalimentaire, en manufacturier, le code est très souvent livré par un intégrateur, un fournisseur de solution verticale ou une équipe en impartition. Deux des changements de cette édition touchent précisément ce que vous ne pouvez pas corriger vous-même — et que vous ne pouvez obtenir que par le contrat et l’exigence de preuve.
La liste
| 2025 | En 2021 | |
|---|---|---|
| A01 | Contrôle d’accès défaillant | 1er — inchangé |
| A02 | Mauvaise configuration de sécurité | 5e → 2e |
| A03 | Défaillances de la chaîne d’approvisionnement logicielle | nouvelle, élargit « composants vulnérables et obsolètes » |
| A04 | Défaillances cryptographiques | 2e → 4e |
| A05 | Injection | 3e → 5e |
| A06 | Conception non sécurisée | 4e → 6e |
| A07 | Défaillances d’authentification | 7e — renommée |
| A08 | Défaillances d’intégrité des logiciels ou des données | 8e — inchangé |
| A09 | Défaillances de journalisation et d’alerte | 9e — renommée |
| A10 | Mauvaise gestion des conditions exceptionnelles | nouvelle |
Le SSRF, catégorie distincte au 10e rang en 2021, est désormais intégré au contrôle d’accès défaillant.
La méthodologie mérite d’être connue, parce qu’elle détermine le poids à accorder à ce classement. L’OWASP a classé douze catégories à partir des données contribuées — environ 175 000 enregistrements de CVE associés à des CWE dans la National Vulnerability Database — et a permis à deux d’entre elles d’être promues par sondage communautaire. Les dix catégories couvrent 248 CWE. L’organisme précise avoir privilégié les causes profondes plutôt que les symptômes, ce qui explique l’essentiel des déplacements.
Ce que ça change quand le code n’est pas le vôtre
La chaîne d’approvisionnement n’est plus une affaire de rustines
C’est le changement le plus lourd de conséquences. L’édition 2021 plaçait « composants vulnérables et obsolètes » au 6e rang, et la plupart des organisations en ont fait une pratique simple : passer un outil d’analyse des dépendances, corriger les vulnérabilités critiques. L’A03:2025 élargit explicitement la portée à « l’ensemble de l’écosystème des dépendances logicielles ».
Autrement dit : le système de construction, le registre de paquets, les identifiants d’intégration continue, le compte du mainteneur, le module que le pipeline télécharge au moment de la compilation. Pas seulement le numéro de version dans le fichier de verrouillage.
Quand un fournisseur livre chez vous, cette chaîne est la sienne, et vous n’en voyez normalement rien.
Ce qu’il faut exiger, par ordre d’utilité réelle :
- Une nomenclature logicielle (SBOM) à chaque livraison, pas une fois à la signature du contrat. Une SBOM produite une seule fois décrit une version qui n’est plus en production six mois plus tard.
- Des artéfacts épinglés et vérifiables — empreintes dans les fichiers de verrouillage, images et actions référencées par empreinte plutôt que par étiquette mobile. Un outil d’analyse vous signale les versions connues comme vulnérables ; l’épinglage vous garantit que vous avez reçu l’artéfact demandé.
- Une description du système de construction du fournisseur : exécuteurs éphémères ou permanents, portée des jetons, durée de vie des identifiants. C’est la question qui met le plus mal à l’aise en appel d’offres, et c’est celle qui distingue le plus les fournisseurs entre eux.
- Un délai contractuel de correction exprimé en jours, distinct pour les vulnérabilités critiques et les autres.
La plupart des contrats d’acquisition logicielle québécois contiennent une clause de sécurité générique et rien de tout cela. Les quatre points ci-dessus tiennent en une page d’annexe et sont vérifiables — ce qui est exactement ce qui manque à la clause générique.
La mauvaise configuration : le risque que l’exploitation vous laisse
La montée du 5e au 2e rang est le plus grand déplacement de la liste. Elle est aussi la plus facile à interpréter comme du bruit statistique. Ce n’en est pas.
La mauvaise configuration est la catégorie qui se dégrade le plus mal à l’échelle. Une application mal configurée est un constat ; un défaut de configuration hérité d’un gabarit et reproduit sur deux cents services est une condition systémique — et elle n’apparaît dans aucune revue de code, puisqu’il n’y a pas de code à réviser.
Surtout, c’est la partie du risque qui reste chez vous après la livraison. Le fournisseur écrit le code ; c’est votre équipe qui exploite l’application, applique les paramètres, gère les accès et hérite des valeurs par défaut.
Ce qu’il faut faire : cesser de traiter la configuration comme un sous-produit du déploiement et la traiter comme du code que l’on révise. Concrètement — recenser d’où viennent vos valeurs par défaut (images de base, gabarits d’infrastructure, échafaudage du cadriciel), choisir les dix paramètres dont l’erreur coûterait le plus cher, et les imposer de façon centrale plutôt que de les documenter. Un paramètre documenté est un paramètre qui dérive.
Si vous exploitez déjà un outil de posture infonuagique, attention : cette catégorie dépasse le plan de contrôle du nuage. Elle inclut les valeurs par défaut du cadriciel applicatif lui-même, que la plupart de ces outils ne voient pas.
La disparition du SSRF est un piège documentaire
Le SSRF n’est pas devenu moins exploitable. L’OWASP l’a intégré au contrôle d’accès défaillant parce que, conformément à son approche par causes profondes, la défaillance sous-jacente est que l’application émet une requête au nom d’un utilisateur sans décider correctement si elle le devrait.
Ce qu’il faut faire : rien sur le plan technique. Mais vérifiez une chose — si le SSRF figure comme ligne distincte dans une matrice de conformité, un plan de test ou une portée de test d’intrusion, il n’a plus de place dans la taxonomie 2025 et disparaîtra silencieusement de la prochaine révision de ces documents. Renommez le contrôle avant qu’il ne devienne une lacune sans propriétaire.
C’est précisément ainsi qu’un changement de taxonomie fait des dégâts réels : pas parce que le risque change, mais parce qu’une ligne disparaît d’un document de portée.
Une catégorie entièrement nouvelle, et personne n’y est prêt
Mauvaise gestion des conditions exceptionnelles couvre 24 CWE et n’a aucun antécédent dans la liste. L’OWASP la décrit comme un logiciel qui « échoue à prévenir, détecter et réagir à des situations inhabituelles et imprévisibles, ce qui mène à des plantages, des comportements inattendus et parfois des vulnérabilités ».
Trois modes de défaillance : l’application ne prévient pas la situation inhabituelle, ne la détecte pas, ou y réagit mal. Parmi les CWE : messages d’erreur divulguant de l’information système (CWE-209), paramètres manquants non gérés (CWE-234), déréférencement de pointeur nul (CWE-476), défaillance en mode ouvert (CWE-636).
Les scénarios donnés par l’OWASP méritent qu’on s’y arrête, parce qu’ils ne ressemblent pas à des failles de sécurité :
- Un téléversement de fichier qui ne libère pas ses ressources sur le chemin d’exception, jusqu’à épuisement du service.
- Une erreur de base de données révélant assez de détails système pour permettre à un attaquant de construire une injection ciblée.
- Une interruption réseau en pleine transaction sans annulation — permettant des transferts en double ou la vidange d’un compte.
Ce que ces trois cas ont en commun : chacun serait classé comme défaut de fiabilité, pas comme vulnérabilité. C’est exactement la raison d’être de la catégorie, et ce qui la rend si difficile à intégrer à un programme existant. Vos outils d’analyse ne les trouveront pas, et votre processus de tri a passé des années à enseigner aux équipes que les problèmes de stabilité vont dans une autre file.
Ce qu’il faut faire : les recommandations de l’OWASP sont inhabituellement concrètes. Capter les erreurs là où elles surviennent plutôt qu’au sommet de la pile. Échouer en mode fermé — annuler la transaction plutôt que de récupérer partiellement. Appliquer limitation de débit, quotas de ressources et étranglement. Centraliser la gestion des erreurs et la journalisation, avec un gestionnaire global comme filet de sécurité et non comme mécanisme principal.
En pratique, le geste le plus rentable est de parcourir vos chemins d’erreur en posant une seule question à chacun : si celui-ci se déclenche dix mille fois en une minute, qu’est-ce qui s’épuise, et qu’est-ce qui reste à moitié fait ?
Par où commencer
Si votre programme de sécurité applicative a été cadré sur la liste de 2021 — et c’est le cas de la plupart, puisque c’est ce que référencent les matrices de conformité et les devis de test d’intrusion — trois de vos priorités viennent de bouger et un chantier n’existe pas encore.
- Reclasser le carnet existant selon le nouvel ordre. Rien de neuf à construire : vous repondérez.
- Élargir la chaîne d’approvisionnement de l’analyse des dépendances vers le système de construction — le vôtre et celui de vos fournisseurs. C’est le plus grand chantier réellement nouveau.
- Corriger la taxonomie dans vos documents avant que le SSRF n’en disparaisse partout en silence.
- Ouvrir les conditions exceptionnelles comme petit chantier délibéré. Commencer par les chemins d’erreur de tout ce qui touche à l’argent, aux fichiers ou aux appels externes.
Une mise en garde, enfin. Le Top 10 est un document de sensibilisation bâti sur des données de CVE : il décrit ce qui est fréquemment observé dans l’industrie, pas ce qui est le plus dangereux dans votre parc. Une plateforme transactionnelle et un système de gestion de dossiers du secteur public ne partagent pas un modèle de menace parce qu’ils partagent un cadriciel. Servez-vous de la liste pour vérifier que rien d’important n’est sans propriétaire — pas comme substitut à la connaissance de l’endroit où résident réellement vos données sensibles.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.