OWASP Top 10:2025

Quoi de neuf et pourquoi c’est important

Conseils utiles pour des applications plus sécuritaires et résilientes

Le Top 10 d’OWASP est la norme mondiale de facto relative aux risques majeurs de cybersécurité pour les applications Web. Il est régulièrement mis à jour à partir des données de vulnérabilités réelles et d’enquêtes menées auprès de la communauté informatique.

Au début de novembre 2025, OWASP a publié son dernier classement des Top 10, introduisant deux nouvelles catégories – Défaillances de la chaîne d’approvisionnement logicielle (qui développe la catégorie « Composants vulnérables et obsolètes ») et Mauvaise gestion des situations exceptionnelles. La Falsification des requêtes côté serveur (FRCS) a été intégrée à la catégorie Contrôle d’accès défaillant. Par ailleurs, les Erreurs de configuration de sécurité sont passées de la 5^e à la 2^e place en raison de la complexité croissante des configurations d’applications. Les risques traditionnels tels que les Défaillances cryptographiques, les Injections et les Conceptions non sécurisées ont reculé dans le classement grâce à l’amélioration des pratiques de sécurité intégrée. Cette mise à jour reflète une évolution plus étendue : d’une approche axée sur la détection des vulnérabilités symptomatiques, on passe à une approche systémique traitant les problèmes reliés à la conception, aux chaînes d’approvisionnement et à la gestion des erreurs. Notre Infolettre de décembre 2025 offre des conseils pratiques pour vous aider à développer des applications plus sécurisées et résilientes.

Les risques relatifs à la cybersécurité des applications Web sont allégoriquement comparables à un Marché en Verre décrit ci-après.

Dans une ville côtière se dressait un marché très animé, entièrement composé d’infrastructure en verre. Chaque étal offrait des produits essentiels : nourriture, cartes, lettres, médicaments et outils. Les murs de verre laissaient pénétrer la lumière du soleil et permettaient de voir les marchandises de loin.

Les commerçants appréciaient cette transparence car les clients pouvaient voir exactement ce qu’ils achetaient. Au fil du temps, de nouveaux arrivants ont construit d’autres étals en verre, connectés par des ponts et des tuyaux qui transportaient des lettres, des pièces de monnaie et des conciliabules.

Un jour, un renard rusé arriva. Ce renard rusé apprit comment le marché fonctionnait et comment le verre pouvait être utilisé contre les propriétaires du Marché en Verre. Certains étals laissaient leurs portes déverrouillées par commodité. D’autres utilisaient des scellés brisés pour chuchoter des secrets. D’autres encore se fiaient aux rumeurs plutôt qu’à la vérification du poids des pièces de monnaie.

Le renard rusé a exploité toutes les petites erreurs et les a transformées en des problèmes plus graves. Les habitants de la ville ont découvert qu’un marché aussi beau et transparent pouvait être pillé non seulement par la force, mais aussi par des ruses subtiles, des signaux mal interprétées et la négligence des voisins.

Les aînés de la ville se sont réunis, ils ont discuté de la manière de résoudre ce problème et ont rédigé des règles : verrouiller les portes, vérifier l’étanchéité des pots, ne jamais prêter ses clés passe-partout et toujours tester la solidité des tuyaux de liaison avant d’y confier un trésor. Ils ont appris aux apprentis à concevoir des murs réparables de l’intérieur, à vérifier chaque pièce de monnaie et chaque messager, et à cartographier les itinéraires empruntés par les renards.

Petit à petit, le Marché en Verre a gagné en sagesse, commerçant en toute sécurité tout en préservant la lumière qui faisait sa singularité.

Personnages du Marché en Verre et ce qu’ils représentent pour la sécurité des applications Web

Plateformes/étals en verre : applications Web publiques présentant des données et des fonctionnalités aux utilisateurs.
Portes non verrouillées : une authentification faible et une mauvaise gestion des sessions favorisent l’usurpation d’identité. Les sessions inactives et une validation insuffisante des identifiants permettent aux cybercriminels d’exploiter des vulnérabilités et d’obtenir un accès non autorisé.
Étanchéité fissurée à l’intérieur des pots/jarres : failles cryptographiques et données confidentielles exposées en raison d’une protection insuffisante. Un chiffrement insuffisant, voire inexistant, expose des données confidentielles.
Canaux de communication vulnérables : communications et API non sécurisées qui fuient ou acceptent des entrées dangereuses. Les messages non validés corrompent le destinataire.
Passages/ponts entre les plateformes : un contrôle d’accès défectueux permet à des personnes d’accéder à des zones interdites. Les utilisateurs atteignent des plateformes restreintes et s’emparent de contenus auxquels ils n’ont pas droit.
Marchands acceptant tout type de paiement : validation insuffisante des entrées et failles d’injection permettant l’utilisation de charges utiles malveillantes. Accepter des entrées non vérifiées compromet la confiance.
Outils désuets et toitures rafistolées : des composantes vulnérables et dépassées qui deviennent des points d’entrée faciles. Des bibliothèques désuètes permettent aux renards/cyberpirates de s’infiltrer.
Clés égarées et clés passe-partout partagées : élévation des privilèges et mauvaise configuration des secrets et identifiants. Secrets stockés accessibles à tout le monde.
Signaux rédigés dans des langues différentes : conception non sécurisée et hypothèses incohérentes entre les services. Ces hypothèses divergentes produisent des échappatoires pour les cyberattaquants. Visibilité publique des secrets et des données personnelles.
Renards/pirates informatiques rusés : cyber-attaques automatisées, cyber-pirates adolescents et adversaires persistants qui exploitent la moindre faiblesse ou vulnérabilité.
Registres ouverts et accessibles → Exposition des données confidentielles : visibilité publique des secrets et des données personnelles.
Palabres non contrôlés des voisins → Journalisation et surveillance insuffisantes : les cyberattaques passent inaperçues jusqu’à ce qu’il soit trop tard.

Conseils abrégés provenant de l’allégorie ci-dessus

Verrouillez les portes en appliquant une authentification forte et des contrôles de session stricts.
Corrigez les failles de sécurité grâce à un cryptage approprié et une gestion rigoureuse des clés.
Testez chaque canal et chaque interface avec une validation des entrées et des contrôles d’accès
Remplacez ou corrigez rapidement les outils désuets et évitez de prêter les clés passe-partout.
Concevez des systèmes qui tiennent compte de l’existence des renards rusés et modélisent leur comportement.

Dans le cadre du projet OWASP (Open Worldwide Application Security Project), la sécurité des applications Web peut être comparée à un Marché en Verre qui est à la fois splendide et fragile. La sécurité des applications Web consiste donc à rendre cet allégorique Marché en Verre résilient sans perdre la lumière qui le valorise. En plus des nombreux contenus substantiels publiés en ligne sur le site Web de la Fondation OWASP, les monographies citées dans la section Ressources et Références de la présente Infolettre de décembre 2025 ont également été consultées, abrégées et adaptées pour la rédaction de plusieurs segments de ce manuscrit.

Aperçu utile d’OWASP

Fondée en 2001 en tant qu’organisation de sécurité informatique spécialisée dans la sécurité Web, la sécurité des applications et l’évaluation des vulnérabilités, et située à Wilmington, au Delaware (États-Unis), OWASP signifie Open Worldwide Application Security Project – une communauté mondiale à but non lucratif qui produit des ressources, des outils et des normes industrielles gratuits, et organise des formations, des ateliers et des conférences sur la cybersécurité afin d’améliorer la sécurité des applications Web dans le monde entier.

Services indispensables offerts par OWASP

Guides et normes : normes pratiques telles que la NVSA (Norme de vérification de la sécurité des applications) et le MMAL (Modèle de maturité de l’assurance logicielle) pour évaluer et améliorer les pratiques de sécurité.
Projets et listes de référence : ressources grandement utilisées comme le Top 10 d’OWASP (risques majeurs des applications Web) et des projets sectoriels tels que la sécurité des API et les menaces automatisées affectant les applications web.
Outils et plateformes d’apprentissage : outils libres et applications volontairement vulnérables pour les tests et la formation, par exemple OWASP ZAP et WebGoat.
Communauté et événements : sections locales, conférences, formations et initiatives bénévoles à travers le monde.

Tous ces types de projets, de plateformes d’apprentissage et les exemples connexes sont conçus, développés, documentés et entretenus par la communauté mondiale d’OWASP.

Pourquoi OWASP est-elle importante pour toutes les organisations y compris les PME?

Référence incontournable de l’industrie informatique : de nombreuses normes, programmes de conformité et développeurs s’appuient sur les publications d’OWASP (par exemple : le Top 10) pour hiérarchiser et communiquer les risques de sécurité des applications Web.
Ressources gratuites et ouvertes/libres : les ressources sont disponibles gratuitement, permettant ainsi aux équipes de toutes tailles d’apprendre, de tester, d’appliquer et d’adopter de meilleures pratiques en matière de sécurité des applications Web.

En bref : les 10 principaux risques pour la sécurité des applications Web selon OWASP

Publiée à chaque quatre ans, OWASP Top 10 est une liste collaborative des risques de sécurité les plus significatifs pour les applications Web. Elle sert de référence pour les tests, l’application, la formation et la priorisation des correctifs.

Figure 1 : Sommaire des principaux risques de sécurité des applications Web selon OWASP Top 10 et pratiques nécessaires d’atténuation

Risques reliés à la sécurité des applications Web

Brèves descriptions

Impact typique sur la cybersécurité

Exemples courants

Pratiques nécessaires d’atténuation

A01

Contrôle d’accès défectueux

Défaillances permettant aux utilisateurs d’agir en dehors de leurs autorisations prévues (contrôles horizontaux, verticaux, d’isolement des locataires et au niveau des objets API).

Accès non autorisé à des données ou fonctions confidentielles; élévation des privilèges; fuites ou manipulations des données.

Accès aux enregistrements d’un autre utilisateur en modifiant un identifiant dans l’URL.

Accès aux données d’autres utilisateurs via des références d’objets non sécurisées (par exemple : modification user_id=123 à user_id=124).

Fonctions réservées pour les administrateurs accessibles aux simples utilisateurs via des éléments d’interface utilisateur masqués ou des URL directes.

1. Appliquer le contrôle d’accès côté serveur, et non côté client.

2. Utiliser des politiques de refus par défaut et tester les limites des rôles.

3. Appliquer une autorisation au niveau des objets pour les API.

A02

Erreur de configuration de sécurité

Les paramètres par défaut non sécurisés, les interfaces de gestion exposées ou les environnements incohérents rendent les systèmes vulnérables.

Exposition de systèmes internes, des identifiants par défaut ou des services inutiles; surface d’attaque amplifiée.

Mots de passe par défaut; répertoires exposés.

Identifiants par défaut non modifiés (par exemple : admin/admin).

Fonctionnalités inutilisées, telles que des messages d’erreur détaillés ou des points de terminaison de débogage exposées en production.

1. Automatiser les configurations de référence sécurisées et la détection des écarts.

2. Désactiver les fonctionnalités et services inutilisés.

3. Renforcer la sécurité des environnements d’infonuagique et de conteneurs à l’aide des points de repère CIS.

A03

Défaillances de la chaîne d’approvisionnement logicielle

Compromissions ou mauvaise gouvernance des dépendances, des pipelines de compilation ou des composantes tierces introduisant du code malveillant ou vulnérable.

Introduction des composantes malveillantes ou vulnérables; compromission des systèmes de compilation ou des dépendances.

Inclusion des paquets source libres compromis (exemple : incident Event Stream sur npm).

Absence de nomenclature logicielle (SBOM) ou d’analyse des dépendances, permettant l’utilisation des bibliothèques désuètes ou malveillantes.

1. Maintenir les SBOM (nomenclatures logicielles).

2. Utiliser des registres de confiance et vérifier les signatures des paquets.

3. Implanter des processus de compilation reproductibles et une analyse des dépendances.

A04

Défaillances cryptographiques

Cryptographie incorrecte, faible ou mal appliquée exposant des secrets, des données au repos ou en transit.

Fuites de données dues à un chiffrement faible ou mal utilisé; divulgation d’identifiants utilisateurs ou de renseignements personnels.

Utilisation d’algorithmes désuets comme MD5 ou SHA-1 pour le hachage des mots de passe.

Absence de protocole HTTPS pour la transmission des données confidentielles.

1. Utiliser des bibliothèques cryptographiques modernes et éprouvées (exemples : libsodium, Bouncy Castle).

2. Appliquer TLS 1.2 ou une version supérieure avec des suites de chiffrement robustes.

3. Stocker les secrets de manière sécurisée (exemples : modules de sécurité matériels, coffres-forts numériques).

A05

Injection

Les données saisies par un cyberattaquant sont interprétées comme du code ou des commandes. Les données non filtrées peuvent entraîner l’exécution de commandes ou de requêtes non intentionnelles (SQL, NoSQL, système d’exploitation, LDAP, etc.).

Exécution de code à distance, exfiltration de données ou compromis total du système par des données malveillantes.

Injection SQL par l’intermédiaire des formulaires de connexion (à titre d’exemple : ‘ OU ‘1’=’1).

Injection des commandes lors du téléchargement de fichiers ou via des points de terminaison exécutant des commandes shell.

1. Utilisez des requêtes paramétrées et des cadres ORM.

2. Validez et filtrez toutes les données saisies par l’utilisateur en fonction du contexte.

3. Appliquez le principe du moindre privilège aux comptes de base des données.

A06

Conception non sécurisée

Absence de sécurité dans l’architecture et la conception. Absence de conception sécurisée prenant en compte les menaces, entraînant des faiblesses systémiques non corrigées par les correctifs au niveau du code.

Faiblesses systémiques échappant aux correctifs; vulnérabilités persistantes d’une version à l’autre ou d’un déploiement à l’autre.

Absence de modélisation des menaces ou d’analyse des cas d’abus durant le développement.

Défauts de logique d’affaires, comme les transferts de fonds illimités sans limitation de débit.

1. Effectuer une modélisation des menaces et une analyse des cas d’abus.

2. Définir les exigences de sécurité dès le début du Cycle de vie du développement logiciel (CVDL).

3. Utiliser des modèles de conception sécurisés et des architectures de référence.

A07

Défaillances d’authentification

Failles d’authentification et de gestion des sessions.

Authentification contournable, gestion défaillante des sessions et mise en œuvre inefficace de l’authentification multifactorielle (AMF).

Prise de contrôle de compte, usurpation d’identité et accès non autorisé en raison d’une authentification faible ou brisée/défaillante.

Mots de passe faibles; jetons réutilisés.

Formulaires de connexion vulnérables aux attaques par force brute sans limitation de débit.

Identifiants de session exposés dans les URL ou stockés de manière non sécurisée.

1. Mettre en œuvre une authentification multifactorielle résistante à l’hameçonnage (par exemple : FIDO2).

2. Utiliser une gestion sécurisée des sessions (durée de vie courte, rotation).

3. Éviter l’authentification par mot de passe autant que possible.

A08

Défaillances d’intégrité des logiciels et des données

Absence de garanties d’intégrité (signature, attestation, provenance) pour le code, les mises à jour ou les données confidentielles.

Altération des mises à jour ou des données confidentielles; déploiement de code non autorisé ou malveillant.

Mises à jour logicielles non signées téléchargées par HTTP.

Fichiers de configuration ou variables d’environnement manipulables sans contrôle d’intégrité.

1. Signer le code, les contenants et les mises à jour.

2. Vérifier l’intégrité à l’exécution (exemples : sommes de contrôle, attestation).

3. Protéger les données confidentielles par l’immuabilité et le versionnage.

A09

Défaillances des enregistrements et des alertes

Manque de détection, de fonctionnalités d’alerte et de capacité de réponse. Télémétrie insuffisante, alertes parasites ou manquantes, et préparation insuffisante en matière d’analyse médico-légale, ce qui retarde la détection et la réponse.

Longue durée de présence des cyberattaquants; violations non détectées. Détection tardive des violations; réponse insuffisante aux cyber-incidents; absence des preuves d’enquête informatique.

Absence de journaux centralisés; alertes manquantes.

Absence de journaux pour les tentatives de connexion infructueuses ou les actions confidentielles.

Aucune alerte n’est déclenchée en cas de comportement suspect, comme l’accès répété aux points de terminaison d’administration.

1. Centraliser les journaux avec un transport et un entreposage sécurisé.

2. Surveiller les anomalies et déclencher des alertes exploitables.

3. Tester régulièrement les procédures d’intervention en cas de cyber-incidents.

A10

Mauvaise gestion des conditions exceptionnelles

Gestion des erreurs entraînant des fuites d’informations confidentielles, des défaillances lors de la gestion des erreurs ou des états de sécurité précaires.

Plantages, dénis de service ou fuites d’informations causée par une gestion inadéquate des erreurs ou une logique de récupération inappropriée.

Traces de pile/paquet accessibles aux utilisateurs sur les pages d’erreur.

Plantages d’applications suite à des exceptions non gérées, provoquant un déni de service.

1. Implanter une gestion des erreurs et une logique de repli sécurisées.

2. Éviter d’exposer les traces de pile/paquet ou les renseignements internes aux utilisateurs.

3. Utiliser des disjoncteurs et des mécanismes de dégradation progressive.

Explications concrètes d’OWASP Top 10, leur importance pour les PME, les causes communes et un résumé des principales pratiques d’atténuation

A01 Contrôle d’accès défectueux

Un contrôle d’accès défaillant survient lorsqu’une application ne parvient pas à définir clairement les droits d’accès des utilisateurs. Les défaillances typiques incluent des contrôles d’autorisation manquants ou incohérents, des références directes aux objets non sécurisés, une élévation de privilèges et des traversées de répertoires exposant des fichiers ou des actions à des utilisateurs non autorisés. Les attaquants exploitent ces failles pour lire ou modifier les données d’autres utilisateurs, effectuer des actions d’administration ou accéder au système via un pivot.

Importance pour les PME : les défaillances d’autorisation permettent aux attaquants d’agir avec des privilèges supérieurs à ceux prévus, entraînant des violations de données, des fraudes ou des interruptions de service.
Causes fréquentes : dépendance aux contrôles côté client, logique d’accès ad hoc dispersée dans le code, identifiants d’objets prévisibles et rôles par défaut trop permissifs.
Principales mesures d’atténuation : appliquer des contrôles côté serveur à chaque requête; adopter des politiques de refus par défaut; centraliser et réutiliser la logique d’autorisation; utiliser le principe du moindre privilège et un contrôle d’accès basé sur les rôles ou les attributs; valider la propriété des objets; effectuer des tests de contrôle d’accès automatisés et manuels.

A02 Erreur de configuration de sécurité

Une mauvaise configuration de sécurité désigne des paramètres incorrects, incomplets ou non sécurisés dans les logiciels, les systèmes ou l’infrastructure informatique, exposant involontairement des vulnérabilités. Ces failles proviennent souvent de configurations par défaut, d’étapes de renforcement de la sécurité négligées ou d’environnements incohérents.

Importance pour les PME : une mauvaise configuration de sécurité est importante car elle produit des vulnérabilités involontaires que les attaquants peuvent facilement exploiter, souvent sans avoir besoin d’outils complexes ni de connaissances techniques approfondies. Ces failles sont parmi les plus courantes et les plus évitables dans les applications Web, mais elles conduisent souvent à des violations de données, à la compromission de systèmes et à des infractions réglementaires.
Causes courantes : identifiants et paramètres par défaut, logiciels et composants non corrigés, contrôles d’accès trop permissifs, messages d’erreur et informations de débogage verbeux, fonctionnalités inutiles activées, configurations d’environnement incohérentes, paramètres d’infonuagique ou de conteneurs inappropriés, paramètres de chiffrement manquants ou faibles, absence de gestion de la configuration.
Principales mesures d’atténuation : renforcer les configurations par défaut, automatiser la gestion de la configuration, appliquer des référentiels de sécurité, rechercher les erreurs de configuration, appliquer le principe du moindre privilège, surveiller et détecter les dérives, sécuriser les paramètres secrets et confidentiels, normaliser les environnements de développement, augmenter les tests sur la production, appliquer des correctifs et des mises à jour fréquents, effectuer des examens réguliers.

A03 Défaillances de la chaîne d’approvisionnement logicielle

Les défaillances de la chaîne d’approvisionnement logicielle surviennent lorsque des vulnérabilités, des compromissions ou des lacunes de gouvernance dans les composantes tierces, les systèmes de compilation ou les pipelines de déploiement introduisent des risques de sécurité dans une application. Ces défaillances ne se limitent pas à l’utilisation de bibliothèques désuètes; elles englobent toute atteinte à l’intégrité, à la sécurité ou à la fiabilité des composantes et des processus qui fournissent le logiciel. Cela inclut : les logiciels malveillants, les outils de compilation ou les pipelines CI/CD compromis, les mises à jour et les binaires non vérifiés ou non signés, les dépendances présentant des vulnérabilités connues ou cachées, l’absence de traçabilité ou de nomenclature logicielle (SBOM).

Importance pour les PME : impact significatif : une seule dépendance compromise peut affecter des milliers d’applications en aval. Difficulté de détection : les attaques contre la chaîne d’approvisionnement contournent souvent les tests de sécurité traditionnels. Violations réelles : des incidents comme SolarWinds, Codecov et Log4Shell illustrent comment les cybercriminels exploitent la confiance dans l’écosystème logiciel.
Causes fréquentes : utilisation des composantes non maintenues ou vulnérables, absence de vérification de l’intégrité des composantes, pipeline CI/CD non sécurisé, nomenclatures logicielles (SBOM) manquantes ou incomplètes, dépendance excessive aux registres publics, analyse insuffisante des dépendances, absence de compilations reproductibles, gouvernance et gestion des risques fournisseurs déficientes.
Principales mesures d’atténuation : maintenir des SBOM pour suivre tous les composants et leurs origines. Utiliser des registres de confiance et vérifier les signatures des paquets. Analyser en continu les dépendances afin de déceler les vulnérabilités et les risques reliés aux licences. Mettre en œuvre des compilations reproductibles et sécuriser les pipelines CI/CD. Appliquer des vérifications d’intégrité et une attestation d’exécution pour les composantes critiques.

A04 Défaillances cryptographiques

Les défaillances cryptographiques signifient que les données confidentielles ne sont pas correctement protégées au repos ou en transit, ou que la cryptographie est mal utilisée. Par exemple : transmission de secrets via HTTP, utilisation de chiffrements faibles ou d’aléatoires inadéquats, mauvaise gestion des clés et stockage des mots de passe sans hachage approprié.

Importance pour les PME : une cryptographie faible ou mal utilisée expose les identifiants, les renseignements personnels, les secrets et les garanties de signature ou de confidentialité, ce qui permet le vol ou la falsification.
Causes fréquentes : développement de solutions cryptographiques maison, algorithmes désuets, clés codées en dur, absence de TLS et validation de certificats incorrecte.
Principales mesures d’atténuation : utiliser TLS pour tout le transport; appliquer des algorithmes éprouvés et des configurations recommandées; hacher les mots de passe avec des algorithmes lents et salés (par exemple : Argon2/Bcrypt/PBKDF2); gérer les clés de manière sécurisée avec du matériel ou des coffres-forts de secrets; renouveler régulièrement les clés et valider l’utilisation de la cryptographie par des audits.

A05 Injection

Une injection se produit lorsqu’une entrée non fiable est interprétée comme du code ou des commandes par des interprètes tels que SQL, les shells du système d’exploitation, LDAP ou les moteurs de modèles. L’injection SQL, l’injection de commandes et l’injection CRLF en sont des exemples courants. Les attaquants conçoivent des entrées qui modifient la structure de la commande ou de la requête prévue.

Importance pour les PME : une injection réussie peut entraîner le vol ou la modification de données, le contournement de l’authentification ou l’exécution de code à distance.
Causes fréquentes : concaténation des entrées utilisateur dans les requêtes ou les commandes, validation insuffisante des entrées et fonctionnalités permissives de l’interprète.
Principales mesures d’atténuation : utiliser des requêtes paramétrées et des instructions préparées; utiliser des API sécurisées qui séparent les données du code; valider et normaliser les entrées; adopter un encodage de sortie pour les contextes tels que HTML/JS; appliquer le principe du moindre privilège aux comptes de base des données; inclure l’analyse statique et les protections d’exécution.

A06 Conception non sécurisée

Une conception non sécurisée désigne l’absence ou l’insuffisance de contrôles de sécurité lors de la conception de l’architecture et des fonctionnalités, engendrant des faiblesses systémiques difficiles à corriger ultérieurement. Elle englobe l’absence de modélisation des menaces, le manque d’exigences de sécurité et l’intégration de modèles non sécurisés dans le produit.

Importance pour les PME : les défauts de conception affectent chaque instance de l’application et nécessitent souvent d’importantes corrections.
Causes fréquentes : absence de modélisation des menaces, sécurité négligée, priorité donnée aux fonctionnalités plutôt qu’aux paramètres de sécurité par défaut et définition imprécise des limites de confiance entre les composantes.
Principales mesures d’atténuation : intégrer la modélisation des menaces aux Cycles de conception; définir explicitement les exigences de sécurité et les cas d’utilisation abusive; utiliser des modèles de conception sécurisés; réaliser des revues d’architecture de sécurité; exiger des critères d’acceptation de sécurité avant la mise en production.

A07 Défaillances d’authentification

Les failles d’authentification et de gestion de session permettent aux cyberattaquants d’usurper l’identité d’autres utilisateurs ou de maintenir des sessions actives. Parmi les problèmes courants, on retrouve le stockage de mots de passe faibles, l’absence d’authentification multifactorielle, la fixation de session, le stockage non sécurisé des jetons et les identifiants de session prévisibles.

Importance pour les PME : la prise de contrôle de compte permet la fraude, l’abus de privilèges et les déplacements latéraux au sein des systèmes.
Causes fréquentes : politiques de mots de passe faibles, stockage non sécurisé des identifiants, exposition des jetons de session aux scripts côté client et absence d’authentification multifactorielle pour les opérations confidentielles.
Principales mesures d’atténuation : utiliser des bibliothèques d’authentification éprouvées, exiger l’authentification multi-facteur pour les actions à haut risque, stocker les secrets en toute sécurité, mettre en œuvre des attributs de témoins sécurisés, faire tourner et invalider les jetons à la déconnexion, appliquer une limitation de débit et une détection des anomalies sur les points de terminaison d’authentification.

A08 Défaillances reliées à l’intégrité des logiciels et des données

Cette catégorie concerne la confiance accordée à du code, des bibliothèques, des artefacts CI/CD ou des mises à jour de données non vérifiés et susceptibles d’être falsifiés. Parmi les exemples courants, mentionnons les versions non signées, l’acceptation de dépendances non fiables ou un pipeline de compilation exposé.

Importance pour les PME : des artefacts de compilation ou des dépendances compromis permettent aux attaquants d’insérer des portes dérobées ou des comportements malveillants dans des logiciels pourtant légitimes.
Causes fréquentes : artefacts non signés, infrastructure de compilation accessible en écriture, absence de contrôles de provenance et dépendance à des registres non fiables.
Principales mesures d’atténuation : signer et vérifier les compilations et les paquets; appliquer le principe du moindre privilège sur le CI/CD; utiliser des compilations reproductibles; figer les versions des dépendances et vérifier les sommes de contrôle; surveiller les avis de la chaîne d’approvisionnement et vérifier l’accès au pipeline.

A09 Défaillances de journalisation et d’alertes

Une journalisation insuffisante, un manque de centralisation, l’absence d’alertes ou une durée de conservation inadéquate des données entravent la détection et la réponse aux cyber-incidents. Sans visibilité adéquate, les violations de données peuvent passer inaperçues pendant longtemps.

Importance pour les PME : une détection tardive aggrave les dommages et complique l’enquête informatique et le confinement.
Causes fréquentes : journaux épars ou incohérents, journalisation incorrecte des données confidentielles, absence de seuils d’alerte et journaux cloisonnés entre les systèmes.
Principales mesures d’atténuation : centraliser les journaux, assurer une collecte de journaux inviolable, consigner les événements pertinents pour la sécurité avec un contexte suffisant, masquer les champs confidentiels, concevoir des alertes exploitables et tester régulièrement les processus de détection et de réponse aux cyber-incidents.

A10 Mauvaise gestion des conditions exceptionnelles

La mauvaise gestion des conditions exceptionnelles désigne les défaillances dans la manière dont les applications réagissent aux états anormaux ou aux erreurs (entrées manquantes, accès refusé, pannes système, etc.) pouvant entraîner des failles de sécurité, des plantages ou des fuites d’informations. Elle se concentre sur la gestion inadéquate des erreurs, l’absence de gestion sécurisée des défaillances et les erreurs logiques survenant lorsque les systèmes rencontrent des circonstances inattendues. Elle regroupe les problèmes auparavant dispersés entre la mauvaise qualité du code et les erreurs d’exécution en une catégorie plus facilement exploitable.

Importance pour les PME : fuites de sécurité : la divulgation de détails internes facilite la cartographie du système par les attaquants. Déni de service : plantages ou blocages dus à des exceptions non gérées. Élévation des privilèges : une erreur d’ouverture peut permettre un accès non autorisé. Faible observabilité : les défaillances silencieuses nuisent à la détection et à la réponse.
Causes fréquentes : exceptions non interceptées, messages d’erreur verbeux, erreur d’ouverture au lieu d’une gestion sécurisée des défaillances, absence de validation des entrées, gestion incorrecte des privilèges, défaillances silencieuses, gestion incohérente des erreurs entre les composantes, absence de dégradation progressive.
Principales mesures d’atténuation : gestion sécurisée des erreurs : en cas d’erreur, privilégier le refus d’accès ou une solution de repli sécurisée. Personnalisation des messages d’erreur : éviter d’exposer la logique interne ou les traces de pile aux utilisateurs. Gestion structurée des exceptions : intercepter et consigner les erreurs sans provoquer l’arrêt du système. Validation des entrées et des états : vérifier tous les paramètres et conditions requis. Tests des cas limites et des scénarios d’abus : inclure des tests d’injection de fautes et de chaos.

Étapes programmatiques pour réduire les 10 principaux risques des applications Web selon OWASP

Mettre en œuvre des pratiques du Cycle de vie de développement logiciel (CVDL) sécurisées : modélisation des menaces, exigences de sécurité, examen du code et tests automatisés (SAST, DAST, SCA) intégrés à l’intégration continuelle et au déploiement continuel (CI/CD).
Appliquer des protections robustes en temps réel : autorisation centralisée, protocole TLS omniprésent, configurations renforcées et journalisation et alertes centralisées.
Maintenir une bonne hygiène logicielle : nomenclature des composants logiciels (SBOM), analyse des dépendances, gestion des correctifs, gestion des secrets et pipelines d’artefacts signés.
Investir dans les ressources humaines et les processus : élaborer des formations sur les bonnes pratiques de sécurité, effectuer des tests d’intrusion réguliers, élaborer des procédures de réponse aux cyber-incidents et mesurer les SLA de détection et de correction.

Liste de contrôle ou plan de remédiation priorisé par pile technologique

Vous trouverez ci-dessous une liste de vérification adaptée aux piles technologiques les plus courantes, ou un plan de remédiation priorisé basé sur les vecteurs d’exploitation et d’impact les plus fréquents pour les risques de sécurité des applications Web.

Figure 2 : Tableau pragmatique des approches recommandées et comparaisons écourtées des piles logicielles

Piles logicielles	Priorités en matière de sécurité	Points faibles communs	Actions immédiates majeures
Node.js / Express	Chaîne d’approvisionnement des dépendances; injection à l’exécution.	Dépendances du gestionnaire de paquets Node (npm) non épinglées; pollution des prototypes; intergiciels non sécurisés.	SCA, CSP strict, requêtes de base des données paramétrées.
Java / Spring	Désérialisation; configuration incorrecte.	Bibliothèques désuètes; points de terminaison permissifs.	Mettez à jour la nomenclature, activez l’authentification des points de terminaison et sécurisez la désérialisation.
.NET / ASP.NET Core	Authentification et gestion des séances; traitement des fichiers.	Témoins non sécurisés; chargements de fichiers non sécurisés.	Imposer des témoins sécurisés, utiliser Identity et valider les chargements.
Python / Django / Flask	Injection par ORM/gabarits; découlement des dépendances.	Modèles non sécurisés; dépendances pipeline non épinglées.	Paramétrisation ORM, échappement automatique des modèles, SCA.
PHP / Laravel / Symfony	Gestion des fichiers non sécurisée; XSS.	Paquets Composer désuets; mauvaise gestion des entrées.	Utilisez l’autorisation du cadre, l’échappement des sorties et l’audit Composer.

Liste de vérification générale des mesures correctives prioritaires : applicable à toute catégorie de piles technologiques

1. Inventaire et visibilité

Créer une nomenclature des ressources système (SBOM) pour toutes les dépendances d’exécution et de compilation.
Centraliser l’inventaire des ressources : applications, API, serveurs, points d’entrée/sortie.

2. Authentification et sécurité des sessions

Appliquer l’authentification multifactorielle (AMF) pour tous les comptes privilégiés et d’administration.
Utiliser des indicateurs de sécurité pour les témoins : Secure, HttpOnly, SameSite.
Renouveler et invalider les jetons lors des changements de mot de passe et des déconnexions.

3. Autorisation et moindre privilège

Centraliser la logique d’autorisation ; appliquer le refus par défaut.
Valider la propriété des objets à chaque accès.
Minimiser les rôles et les permissions de service pour chaque composante.

4. Protection des données et cryptographie

Utiliser TLS partout avec des suites de chiffrement modernes et HSTS.
Hacher les mots de passe avec Argon2/Bcrypt/PBKDF2 et procéder à leur salage.
Gérer les clés dans un coffre-fort et les renouveler régulièrement.

5. Hygiène des dépendances et de la chaîne d’approvisionnement

Activer l’authentification forte du client (SCA) dans l’intégration continuelle (CI) pour bloquer les vulnérabilités critiques (CVE).
Épingler les versions des dépendances et vérifier les sommes de contrôle ou les signatures.
Limiter l’exécution des scripts tiers et examiner les dépendances transitives.

6. Sécurité des entrées/sorties

Utiliser des requêtes paramétrées et des API sécurisées; ne jamais concaténer des requêtes SQL.
Échapper/encoder les sorties HTML, JS, CSS, URL et attributs.
Valider rigoureusement les entrées avec des listes blanches et la canonisation.

7. Sécuriser la compilation et le déploiement

Signer et vérifier les artéfacts; restreindre les autorisations CI/CD.
Utiliser des compilations immuables et le déploiement automatisé (IaC).
Analyser les images de conteneurs et minimiser les images de base.

8. Configuration et renforcement de la sécurité

Renforcer la sécurité des valeurs par défaut; supprimer les services et les points de terminaison inutilisés.
Automatiser les vérifications de configuration et la détection des dérives.
Éviter d’entreposer des secrets dans le code ou les dépôts; utiliser des gestionnaires de secrets.

9. Journalisation, surveillance et réponse

Centraliser les journaux et assurer leur intégrité.
Consigner les événements de sécurité dans un contexte suffisant et masquer les informations confidentielles.
Définir des seuils d’alerte et exécuter des exercices de simulation de cyber-incident.

10. Protections en temps réel et contrôles du réseau

Mettre en œuvre un pare-feu applicatif Web (WAF) et une limite de débit pour les terminaux publics.
Filtrage du trafic sortant et segmentation du réseau interne.
Contrôles d’intégrité en temps réel et solution EDR basée sur l’hôte ou un agent, le cas échéant.

Listes de contrôle propres à chaque pile technologique pour tout type d’organisation

Node.js / Express

Gestion des dépendances : activer npm audit/Snyk/GitHub Dependabot; figer package.json; utiliser package-lock.json.
Sécurité d’exécution : éviter Eval, Fonction et les moteurs de modèles non fiables; utiliser Helmet pour les en-têtes.
Base de données : utiliser des requêtes paramétrées ou des requêtes préparées ORM.
API : valider les schémas JSON; limiter la taille et le débit du corps des requêtes.
Construction : signer les artefacts; l’intégration continuelle exécute SAST et SCA; minimiser les images de conteneur.

Java / Printemps

Dépendances : utiliser une nomenclature d’utilisation du code (SBOM); exécuter OWASP dependency-check; mettre à jour rapidement les composantes Spring.
Désérialisation : désactiver la désérialisation Java par défaut; utiliser des sérialiseurs sécurisés.
Sécurité des points de terminaison : centraliser avec Spring Security; appliquer une protection CSRF aux opérations modifiant l’état.
Configuration : externaliser les secrets dans un coffre-fort numérique. Évitez d’exposer les points de terminaison Actuator au public.
Surveillance : activez les journaux structurés et corrélez-les avec les identifiants de trace.

.NET / ASP.NET Core

Authentification : utilisez ASP.NET Identity ou Azure AD; exigez l’authentification multifactorielle (AMF) pour les rôles d’administrateur.
Témoins et séances : appliquez SameSite=Lax/Strict lorsque cela est approprié.
Téléchargements des fichiers : validez le type, recherchez les logiciels malveillants et stockez les fichiers en dehors de Webroot.
Dépendances : effectuez des audits NuGet; gardez l’environnement d’exécution à jour.
Hôte : activez Kestrel TLS et désactivez les points de terminaison de débogage en production.

Python / Django / Flask

Modèles : privilégiez l’échappement automatique; évitez les fonctionnalités de modèles non sécurisées.
Utilisation d’ORM : utilisez les paramètres de requête et les API de requête ORM plutôt que le SQL brut.
Environnements virtuels : définissez le fichier requirements.txt et utilisez pip-audit/Safety.
Secrets : utilisez des variables d’environnement avec un coffre-fort; évitez de les sauvegarder dans le fichier → .env.
WSGI : exécuter derrière une procuration (proxy) inverse renforcée; limiter les en-têtes serveur exposés.

PHP / Laravel / Symfony

Fonctionnalités du cadre : utiliser les fonctionnalités intégrées de protection CSRF, d’authentification et de validation.
Composer : exécuter « composer audit » et verrouiller les versions dans « composer.lock ».
Encodage de la sortie : utiliser l’échappement Blade/Twig par défaut; échapper aux sorties brutes.
Téléversements : appliquer des contrôles MIME et d’extension stricts; stocker les fichiers hors du répertoire public.
Configuration : désactiver le mode débogage en production; sécuriser les permissions du fichier « .env ».

Plan d’intervention rapide sur 7 jours pour les listes de contrôle spécifiques à la pile technologique

Jours 1 et 2

Inventaire et analyse des vulnérabilités à haut risque
Générer une nomenclature des vulnérabilités (SBOM); exécuter une analyse de la sécurité des certificats (SCA) et une analyse rapide des vulnérabilités (DAST) sur les points de terminaison publics.

Jours 3 et 4

Authentification et contrôle d’accès
Mettre en place l’authentification multifactorielle (AMF) pour les administrateurs; vérifier les rôles et révoquer les autorisations excessives.

Jour 5

Correctifs et actions relatives aux dépendances
Corriger les vulnérabilités critiques/élevées (CVE); figer et tester les mises à niveau des dépendances.

Jour 6

Journalisation et détection
Centraliser les journaux; créer au moins trois alertes pour les échecs d’authentification, les modifications de privilèges et les taux d’erreur élevés.

Jour 7

Déploiement des mesures d’atténuation
Ajouter des règles WAF, des limites de débit et activer le renforcement TLS; valider par des tests de non-régression.

Comment les PME canadiennes peuvent-elles réduire davantage les 10 risques majeurs de sécurité des applications Web selon OWASP ?

Les PME canadiennes peuvent réduire davantage les risques reliés à la sécurité des applications Web figurant dans le Top 10 d’OWASP en adoptant des pratiques de sécurité légères et évolutives, axées sur des paramètres par défaut sécurisés, l’automatisation et la sensibilisation du personnel, sans nécessiter des ressources de niveau entreprise. Voici un aperçu commode adapté aux PME opérant partout au Canada :

1. Prioriser les paramètres sécurisés par défaut

Utiliser des cadres et des plateformes qui imposent des paramètres de sécurité par défaut (exemples : témoins sécurisés, protection CSRF).
Désactiver les fonctionnalités inutilisées, les messages d’erreur détaillés et les points de terminaison de débogage en production.

2. Automatiser les contrôles de sécurité

Intégrer des outils d’analyse statique et dynamique dans les pipelines CI/CD (exemples : Snyk, OWASP ZAP, SonarQube).
Utiliser des analyseurs de dépendances pour détecter rapidement les paquets vulnérables.

3. Prioriser le contrôle d’accès et l’authentification

Mettre en œuvre un contrôle d’accès basé sur les rôles (RBAC) et effectuer des tests d’élévation des privilèges.
Utiliser une authentification multi-facteur (AMF) résistante à l’hameçonnage (exemple : FIDO2) et une gestion sécurisée des sessions.

4. Renforcer la configuration et l’infrastructure

Appliquer les tests de performance CIS pour les serveurs, les conteneurs et les services infonuagiques.
Utiliser des outils d’infrastructure en tant que code (IaC) comme Terraform avec des modules de sécurité.

5. Gérer les risques relatifs à la chaîne d’approvisionnement logicielle

Maintenir une nomenclature logicielle (SBOM) pour tous les projets.
Utiliser des registres de confiance et vérifier les signatures des paquets.
Vérifier régulièrement les composantes et les fournisseurs tiers.

6. Conception sécurisée et modélisation des menaces

Utiliser OWASP Threat Dragon ou des outils similaires pour une modélisation simplifiée des menaces.
Définir les exigences de sécurité dès les premières étapes du Cycle de développement.

7. Améliorer la journalisation et la surveillance

Centraliser les journaux à l’aide d’outils comme la suite ELK ou une solution de journalisation native de l’infonuagique.
Configurer des alertes pour les comportements suspects (exemples : défaillances de connexion, modifications des privilèges).

8. Gérer les erreurs en toute sécurité

Nettoyer les messages d’erreur pour éviter toute fuite de logique interne.
Mettre en œuvre une gestion structurée des exceptions et une dégradation progressive.

9. Former et responsabiliser le personnel

Offrir une formation sur les 10 principales vulnérabilités OWASP aux développeurs et aux testeurs.
Promouvoir une culture de sécurité par des séances de sensibilisation régulières.

10. Effectuer des vérifications de sécurité régulières

Planifier des vérifications et des tests d’intrusion périodiques (même légers).
Utiliser OWASP ASVS ou MASVS comme liste de contrôle pour un développement sécurisé.

Figure 3: Outils pratiques pour les PME canadiennes afin d’atténuer les risques d’OWASP Top 10

Outils pratiques	Objectifs
OWASP ZAP	Numériseur dynamique gratuit pour des applications Web
Threat Dragon	Modélisation légère des menaces
Snyk/Dependabot	Analyse des vulnérabilités reliées aux dépendances
CIS Benchmarks	Guides de renforcement de la configuration
Security Headers	Analyse rapide des en-têtes HTTP

Approches faisables : mesures de réduction OWASP Top 10 pour les PME canadiennes travaillant avec des clients de l’Union européenne dans le cadre du RGPD ou du Règlement de l’Union européenne sur la cyber-résilience

Les approches ci-dessous permettent aux PME canadiennes de se conformer aux attentes et aux exigences légales du RGPD ou du Règlement de l’Union européenne sur la cyber-résilience (CRA) 2024/2847, tout en abordant les 10 principaux cyber-risques d’OWASP.

1. Contrôle d’accès et authentification

Appliquer le contrôle d’accès basé sur les rôles (RBAC) avec isolation multi-locataire.
Activer une authentification multifactorielle résistante à l’hameçonnage (exemple : FIDO2).
Sécuriser la gestion des sessions (courte durée de vie, rotation, invalidation).

2. Configuration et infrastructure

Appliquer les tests de performance CIS aux serveurs, conteneurs et services infonuagiques.
Automatiser les configurations de base sécurisées (outils IaC comme Terraform).
Désactiver les fonctionnalités inutilisées, les messages d’erreur détaillés et les points de terminaison de débogage.

3. Chaîne d’approvisionnement logicielle

Maintenir les nomenclatures logicielles (SBOM) pour toutes les applications déployées.
Analyser les dépendances afin de déceler les vulnérabilités et les risques relatifs aux licences.
Utiliser des registres de confiance et vérifier les signatures des paquets.

4. Cryptographie et intégrité des données

Appliquer TLS 1.2+ avec des suites de chiffrement robustes.
Utiliser des bibliothèques cryptographiques modernes (exemple : libsodium).
Signer le code, les contenants et les mises à jour.

5. Validation des intrants et prévention des injections

Utiliser des requêtes paramétrées et des cadres ORM.
Valider et nettoyer toutes les entrées utilisateur en fonction du contexte.
Appliquer le principe du moindre privilège aux systèmes des terminaisons.

6. Conception sécurisée et modélisation des menaces

Effectuer une modélisation des menaces simplifiée (exemple : OWASP Threat Dragon).
Définir les exigences de sécurité dès les premières étapes du Cycle de vie du développement logiciel (CVDL).
Utiliser des modèles de conception sécurisés et des architectures de référence.

7. Journalisation et surveillance

Centraliser les journaux avec un transport et un entreposage sécurisé.
Surveiller les anomalies et déclencher des alertes exploitables.
Tester régulièrement les procédures d’intervention en cas d’incidents.

8. Gestion des erreurs et des cas exceptionnels

Nettoyer les messages d’erreur pour éviter les fuites de logique interne.
Mettre en œuvre une gestion structurée des exceptions et une dégradation progressive.
Gérer les défaillances de manière sécurisée et journaliser tous les cas anormaux.

Contrôles transversaux économiques et efficaces pour les PME

Automatiser les analyses dans l’intégration continuelle : analyse statique de code (SAST) pour détecter les anomalies, analyse statique de code (SCA) pour les dépendances et analyse dynamique de code (DAST) simple pour les points de terminaison publics ; bloquer les compilations en cas de problèmes critiques.
Utiliser des services gérés pour l’authentification (Auth0, Azure AD B2C) et la gestion des secrets (AWS Secrets Manager, Azure Key Vault) afin de déléguer les tâches complexes.
Déployer un pare-feu applicatif Web (WAF) de base et des règles de limitation de débit pour les points de terminaison publics; activer TLS et HSTS via des équilibreurs de charge managés.
Effectuer des analyses externes trimestrielles et au moins un test d’intrusion ou un audit ciblé par année pour les applications Web critiques.

Feuille de route minimale (30/60/90 jours)

0 à 30 jours : inventaire (nomenclature des processus, actifs), activation du protocole TLS, mise en place de l’authentification multifactorielle pour les administrateurs, activation des alertes de dépendances dans le dépôt.
31 à 60 jours : ajout des analyses d’intégration continuelle (SAST + SCA), centralisation des journaux et des trois principales alertes, correction des vulnérabilités critiques/élevées (CVE).
61 à 90 jours : modélisation des menaces sur les flux principaux, déploiement des règles WAF, signature des artefacts et renforcement des autorisations d’intégration continue/déploiement continu (CI/CD).

Outils et ressources économiques abordables pour les PME

Analyseurs de dépendances : Dependabot (GitHub), GitLab SCA, npm audit, pip-audit, Trivy pour les conteneurs.
Options SAST/DAST : versions gratuites d’outils open source et éditions communautaires (exemple : OWASP ZAP pour DAST).
Gestion des secrets et authentification : privilégier les solutions infonuagiques et les fournisseurs d’identité plutôt que les solutions internes.
Formation : une courte formation ciblée pour développeurs (1 à 2 heures) sur l’injection de dépendances, l’authentification et le contrôle d’accès est immédiatement rentable.

Recommandations ultimes pour l’intégration d’OWASP Top 10 dans le CVDL et la stratégie de conformité

Commencez par une visibilité optimale (inventaire + vérifications automatisées des dépendances), renforcez l’authentification et le contrôle d’accès, centralisez la journalisation et les alertes, ensuite étendez le processus aux vérifications automatisées du code et de l’exécution. Mettez en œuvre des mesures correctives itératives à court terme afin de réduire rapidement les cyber-risques les plus importants.

Vous trouverez ci-dessous une feuille de route personnalisée pour aider les PME canadiennes à intégrer OWASP Top 10:2025 à leur Cycle de vie de développement logiciel (CVDL) et à leur stratégie de conformité. Cette feuille de route est particulièrement pertinente pour les PME canadiennes travaillant avec des clients européens dans le cadre de réglementations telles que le RGPD ou le Règlement de l’Union européenne sur la cyber-résilience (CRA) 2024/2847.

PHASE 1 : Fondements et sensibilisation

Objectif : Établir une compréhension commune d’OWASP Top 10 et de leur pertinence pour vos opérations commerciales et vos obligations réglementaires.

Offrir une formation sur les 10 principaux risques d’OWASP aux développeurs, aux équipes d’assurance qualité et aux équipes de production.
Faire correspondre les risques OWASP avec les exigences essentielles de la CRA 2024/2847 et les principes de cybersécurité du RGPD.
Adopter OWASP ASVS comme dépôt pour le développement et les tests logiciels sécurisés.
Définir les rôles et les responsabilités en matière de sécurité tout au long du Cycle de vie du développement logiciel (CVDL).

PHASE 2 : Conception et architecture

Objectif : Intégrer la sécurité dès le début de la fabrication logicielle grâce à une conception sécurisée et à la modélisation des menaces.

Intégrer la recommandation A06 : Conception non sécurisée aux revues d’architecture.
Utiliser OWASP Threat Dragon ou STRIDE pour une modélisation simplifiée des menaces.
Définir les exigences de sécurité pour chaque fonctionnalité (exemple : contrôle d’accès, journalisation, cryptographie).

PHASE 3 : Développement et intégration

Objectif : Prévenir les vulnérabilités grâce à un codage sécurisé, une gestion rigoureuse des dépendances et l’automatisation.

Appliquer les normes de codage sécurisé conformes à OWASP Top 10.
Rechercher les vulnérabilités A03 : Défaillances de la chaîne d’approvisionnement logicielle à l’aide d’outils tels que Snyk/Dependabot ou OWASP Dependency-Check.
Mettre en œuvre une authentification sécurisée (A07), la validation des entrées (A05) et la gestion des erreurs (A10).
Maintenir les nomenclatures logicielles (SBOM) et vérifier l’intégrité des composantes.

PHASE 4 : Test et vérification

Objectif : Détecter OWASP Top 10 avant le déploiement.

Intégrer des outils de test statiques (SAST), dynamiques (DAST) et interactifs (IAST).
Effectuer des tests de robustesse et des tests de scénarios d’abus pour A10 : Conditions exceptionnelles.
Utiliser OWASP ZAP ou Burp Suite pour tester les vulnérabilités A01 à A05.
Valider la couverture des journaux, des alertes et de la télémétrie (A09).

PHASE 5 : Déploiement et opérations

Objectif : Assurer une configuration sécuritaire, l’observabilité et la préparation aux incidents.

Renforcer la sécurité des environnements contre les risques reliés à une Erreur de configuration de sécurité (A02) en utilisant les référentiels CIS.
Surveiller les anomalies et assurer l’intégrité des journaux (A09).
Mettre en œuvre des contrôles d’intégrité en temps réel pour les défaillances d’intégrité des logiciels et des données (A08).
Préparer des procédures de notification des violations de données conformes à l’Article 33 du RGPD.

PHASE 6 : Amélioration continuelle

Objectif : Maintenir la maturité en matière de sécurité et la conformité réglementaire.

Effectuer des audits de sécurité réguliers et des analyses des écarts d’OWASP Top 10.
Mettre à jour les modèles de menaces et les SBOM à chaque nouvelle version.
Rester informé des projets OWASP (exemple : API Top 10, MASVS, CycloneDX).
Se conformer à l’évolution des recommandations CRA 2024/2847 et ENISA.

Conclusion

La publication OWASP Top 10:2025 restera le principal aperçu consensuel des risques majeurs relatifs aux applications Web, tout en évoluant pour refléter les nouvelles technologies, les méthodes des cyberattaquants et les pratiques de distribution des logiciels. Les prochaines éditions mettront l’accent sur les causes profondes, la complexité des systèmes et les risques pertinents à l’écosystème informatique, plutôt que sur les seuls types d’exploitation.

Les normes OWASP Top 10:2025 marquent un tournant primordial vers la résilience systémique, la conception sécurisée et l’intégrité de la chaîne d’approvisionnement – notamment les tendances qui façonneront les futures priorités, outils et cadres de conformité en matière de sécurité des applications. Voici un bref aperçu des I-Tendances émergentes et des II-Perspectives issues du Rapport d’OWASP Top 10:2025 et quelques prévisions des experts.

I – Principales tendances qui façonneront le contenu des futurs OWASP Top 10

1. Priorité à la cause originelle plutôt qu’à la correction des symptômes

OWASP est en train de délaisser les vulnérabilités isolées au profit des failles architecturales sous-jacentes.
Des catégories telles que « Conception non sécurisée » et « Gestion incorrecte des conditions exceptionnelles » mettent l’accent sur un comportement sécurisé par défaut, et non plus seulement sur l’application de correctifs.

2. La sécurité de la chaîne d’approvisionnement : une préoccupation majeure

La norme « Défaillances de la chaîne d’approvisionnement logicielle » (A03:2025) reflète la menace croissante que représentent les dépendances compromises, les pipelines de compilation et les intégrations tierces.
Il faut s’attendre à une adoption accrue des nomenclatures logicielles (SBOM), de l’attestation des dépendances et des contrôles d’intégrité à l’exécution.

3. Résilience opérationnelle et observabilité

La norme « Journalisation et alertes en cas de défaillance » (A09:2025) souligne la nécessité de la télémétrie, de la détection des anomalies et de la préparation aux incidents.
Les futurs outils privilégieront l’analyse des enquêtes informatiques, la fiabilité des alertes et l’automatisation des réponses.

4. Conception sécurisée et modélisation des menaces

La norme « Conception non sécurisée » (A06:2025) encourage les bonnes pratiques de sécurité dès les premières étapes du développement, comme l’analyse des cas d’abus, les modèles d’architecture sécurisée et les contrôles dès la conception.
Les outils de modélisation des menaces (exemple : OWASP Threat Dragon) seront davantage intégrés aux pipelines du Cycle de vie du développement logiciel (CVDL).

5. Risques relatifs à l’infonuagique et aux API

Bien que ce ne soit pas une catégorie indépendante, les erreurs de configuration de l’infonuagique et des API sont incluses dans les risques reliés aux « Erreurs de configuration de sécurité » et aux « Défaillances du contrôle d’accès ».
Les recommandations futures d’OWASP pourraient inclure un Top 10 spécifique aux API, la sécurité des conteneurs et la gestion de la posture multi-infonuagique.

6. IA et automatisation dans la sécurité des applications

Avec le développement du code généré par l’IA et des tests basés sur l’IA, OWASP pourrait évoluer pour aborder l’exposition des modèles d’IA, l’injection des vulnérabilités et la détection automatisée des exploitations de vulnérabilités.
Les projets futurs d’OWASP devraient explorer les risques propres à l’IA et sécuriser les processus d’apprentissage automatique.

II – Perspectives d’adoption et d’influence d’OWASP Top 10

Alignement réglementaire : OWASP Top 10:2025 sera de plus en plus souvent référencé dans des cadres réglementaires tels que le RGPD, CRA 2024/2847, PCI DSS et ISO/IEC 27001.
Formation et certification : les catégories OWASP influencent la formation des développeurs, les normes de codage sécurisé et les certifications en sécurité applicative.
Intégration des outils : les numériseurs de sécurité, les plateformes CI/CD et les outils d’évaluation de la sécurité infonuagique sont en train d’intégrer nativement les contrôles OWASP.

Observations factuelles finales

OWASP Top 10 demeurera la norme et la référence incontournable en matière des risques de sécurité des applications Web. Induits par l’infonuagique, les API et l’automatisation, elle évoluera des classements de vulnérabilités individuelles vers des risques systémiques, centrés sur l’architecture informatique et la chaîne d’approvisionnement logicielle. Les organisations qui adoptent une conception axée sur les menaces, une gouvernance continuelle des dépendances et une observabilité en temps réel seront les mieux placées pour se prémunir contre les vulnérabilités à être révélées par les futures publications d’OWASP Top 10 concernant les risques de sécurité des applications Web.

Ressources et références

Open Worldwide Application Security Project – site Web multidimensionnel de la Fondation OWASP. OWASP Top 10:2025 – Risques reliés à la sécurité des applications Web : version candidate n° 1 (RC1) du 6 novembre 2025. Connaissances et contenus multicouches en cybersécurité publiés en ligne. Siège social d’OWASP – Wilmington, Delaware, USA. Hyperlien 1: Introduction – OWASP Top 10:2025 RC1 Hyperlien 2: OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation
Jinfeng Li et Haorong Li. “Evolution of Application Security based on OWASP Top 10 and CWE/SANS Top 25 with Predictions for the 2025 OWASP Top 10” dans la compilation de la sélection 2025 International Conference on Inventive Computation Technologies (ICICT) – Kirtipur, Népal – 23 au 25 avril 2025. Publié par IEEE Xplore Digital Library le 23 mai 2025. Evolution of Application Security based on OWASP Top 10 and CWE/SANS Top 25 with Predictions for the 2025 OWASP Top 10 | IEEE Conference Publication | IEEE Xplore
Min, N.M., Visoottiviseth, V., Teerakanok, S. et Yamai, N. dans la compilation de la sélection 24^th International Conference on Advanced Communication Technology (ICACT), publié par Scientific Research Open Access – An Academic Publisher: Pyeongchang, Corée du Sud, 13 au 16 février 2023, pp. 317-322. Min, N.M., Visoottiviseth, V., Teerakanok, S. and Yamai, N. (2022) OWASP IoT Top 10 Based Attack Dataset for Machine Learning. 2022 24th International Conference on Advanced Communication Technology (ICACT), PyeongChang Kwangwoon_Do, 13-16 February 2022, 317-322. – References – Scientific Research Publishing
Davide Fucci, Emil Alégroth, Michael Felderer et Christoffer Johannesson. “Evaluating Software Security Maturity Using OWASP SAMM: Different Approaches and Stakeholders Perceptions” dans The Journal of Systems and Software, volume 214 – août 2024, séries 112062, publié par ScienceDirect – Elsevier, Amsterdam, Pays-Bas. Article en libre accès publié sous licence Creative Commons – Evaluating software security maturity using OWASP SAMM: Different approaches and stakeholders perceptions – ScienceDirect
Shao-Fang Wen et Basel Katt. “A Quantitative Security Evaluation and Analysis Model for Web Applications Based on OWASP Application Security Verification Standard” dans Computers and Security Journal, volume 135 – décembre 2023, séries 103532, publié par ScienceDirect – Elsevier, Amsterdam, Pays-Bas. Article en libre accès publié sous licence Creative Commons – A quantitative security evaluation and analysis model for web applications based on OWASP application security verification standard – ScienceDirect
Rob Botwright et al. OWASP Top Ten Vulnerabilities: Beginner’s Guide to Web Application Security Risks, 4 livres en 1 paquet, 2^e édition en format papier, Morden, Londres, Angleterre (Royaume Uni): conjointement publié par Google Books et Pastor Publishing Co. Ltd., 11 janvier 2024, 392 pages. Hyperlien 1: OWASP Top 10 Vulnerabilities: Beginner’s Guide To Web Application Security Risks – Rob Botwright – Google Books Hyperlien 2: OWASP Top 10 Vulnerabilities: Beginner’s Guide To Web Application Security Risks: Botwright, Rob: 9781839386299: Books – Amazon.ca
Landen Howe. Practical OWASP Security Testing: Hands-On Strategies for Detecting and Mitigating Web Vulnerabilities in the Age of AI, 1^ère édition originale publiée en livre broché et en version numérique, Seattle, Washington, USA: Amazon Publishing USA, 18 juillet 2025, 165 pages, ISBN: 979-8293086450. Practical OWASP Security Testing: Hands-On Strategies for Detecting and Mitigating Web Vulnerabilities in the Age of AI: Howe, Landen: 9798293086450: Books – Amazon.ca
Rajesh Dangi. OWASP for Secure Web Applications, dans la série Computer Science and Information Technology, 1^ère édition en format papier, Chennai, Tamil Nadu, Inde: Notion Press Print Media, 1^eraoût 2024, 178 pages. Hyperlien 1: OWASP for Secure Web Applications Hyperlien 2: OWASP for Secure Web Applications: Rajesh Dangi: 9798895194348: Books – Amazon.ca
Bryan Schroeder. OWASP Application Security Practitioner Exam Prep: 500 Practice Questions with Detailed Explanations, 1^ère édition originale publiée en livre broché et en version numérique. Seattle, Washington, USA: Amazon Publishing USA, 11 août 2025, 309 pages, ISBN: ‎979-8297491144. OWASP Application Security Practitioner Exam Prep: 500 Practice Questions with Detailed Explanations: Schroeder, Bryan: 9798297491144: Books – Amazon.ca
Daniel Finnian. Cyber Security for Developers with OWASP and Security Headers: A Programmer’s Blueprint for Fortifying Web Services Against Critical Vulnerabilities, 1^ère édition originale publiée en livre broché et en version numérique. Seattle, Washington, USA: Amazon Publishing USA, 2septembre 2025, 186 pages, ISBN: ‎979-8263575267.Cyber Security For Developers With OWASP And Security Headers: A programmer’s Blueprint For Fortifying Web Services Against Critical Vulnerabilities: Finnian, Daniel: 9798263575267: Books – Amazon.ca
Taylor Chadwick. End-to-End Web App Protection with OWASP ASVS: Step-by-Step Methods to Harden Authentication, Access Control, Encryption, and Serverless Deployments, 1^ère édition originale publiée en livre broché et en version numérique. Seattle, Washington, USA: Amazon Publishing USA, 29 juillet 2025, 291 pages, ISBN: ‎979-8294673376. End-to-End Web App Protection with OWASP ASVS: Step-by-Step Methods to Harden Authentication, Access Control, Encryption, and Serverless Deployments: Chadwick, Taylor: 9798294673376: Books – Amazon.ca

Contributions

Nous remercions en particulier le Conseil national de recherches du Canada (CNRC) pour son soutien financier par le biais de son Programme d’aide à la recherche industrielle (PARI), lequel programme est bénéfique pour les PME innovatrices à travers les 10 provinces et 3 territoires du Canada.

Éditeur-en-chef de l’infolettre :

Alan Bernardi, SSCP, PMP, auditeur principal pour ISO 27001, ISO 27701 et ISO 42001
B.Sc. Informatique et Mathématiques, Université McGill, Canada
Diplôme d’études supérieures en gestion, Université McGill, Canada

Auteur-Amazon USA, informaticien, rédacteur & traducteur professionnel certifié :

Ravi Jay Gunnoo, C.P.W. ISO 24495-1:2023 & C.P.T. ISO 17100:2015
B.Sc. Informatique et Cybersécurité, Université McGill, Canada
B.Sc. & M.A. Traduction Professionnelle, Université de Montréal, Canada

Ce contenu est publié sous licence Creative Commons Attribution (CC BY-NC).