OWASP Top 10 2025 : la liste actualisée expliquée (A01-A10)

Ce qu'est l'OWASP Top 10 2025, et ce qui a changé

L'OWASP Top 10 est un document de sensibilisation communautaire qui classe les risques de sécurité les plus critiques pour les applications web. Maintenu par l'Open Worldwide Application Security Project, il est actualisé environ tous les trois à quatre ans à partir de données de tests applicatifs contribuées et d'une enquête auprès des praticiens : chaque édition reflète donc le comportement réel des attaquants plutôt qu'une théorie abstraite.

L'édition 2025 maintient le contrôle d'accès défaillant en tête et continue de traiter des catégories entières de faiblesses, et non des bogues isolés. Les évolutions marquantes sont une insistance accrue sur les configurations non sécurisées dans le cloud et les chaînes CI/CD, la montée en puissance du risque lié à la chaîne d'approvisionnement logicielle au-delà des seuls composants vulnérables, et une attention explicite aux erreurs et exceptions mal gérées qui laissent fuiter des données ou échouent en mode ouvert.

Comme de nombreux référentiels et régulateurs y font référence, le Top 10 est devenu une base de fait. Les attentes d'audit de CERT-In en Inde, les exigences de sécurité de la RBI et du SEBI, les régimes européens NIS2 et DORA, ainsi que les questionnaires de sécurité des grandes entreprises américaines supposent tous que vos applications ont été testées contre ces catégories. Considérez cette liste comme le périmètre minimal, pas comme la ligne d'arrivée.

A01 : Contrôle d'accès défaillant

Le contrôle d'accès détermine ce qu'un utilisateur authentifié a le droit de faire. Il est défaillant lorsqu'un utilisateur peut agir au-delà de ses permissions : consulter les enregistrements d'autres clients en modifiant un identifiant dans l'URL, obtenir un rôle d'administrateur ou atteindre des API qui devraient lui être interdites. Cette catégorie reste la plus fréquente et la plus dommageable des éditions récentes.

Mesure de protection : refuser par défaut et appliquer l'autorisation côté serveur à chaque requête, en vérifiant la propriété de l'objet précis auquel on accède plutôt que de faire confiance aux identifiants fournis par le client ou aux champs masqués.

A02 : Mauvaise configuration de sécurité

Cette catégorie couvre les paramètres par défaut non sécurisés, les fonctionnalités inutiles laissées actives, les pages d'erreur verbeuses, les en-têtes de sécurité absents, le stockage cloud ouvert et les services non corrigés ou surprivilégiés. L'édition 2025 lui donne davantage de poids, car la prolifération du cloud, des conteneurs et des chaînes CI/CD multiplie les endroits où un seul réglage faible peut exposer des données.

Mesure de protection : construire des bases de configuration durcies et reproductibles sous forme de code, supprimer les composants inutilisés et les comptes par défaut, et analyser en continu les environnements en production pour détecter les dérives avant qu'un attaquant ne les découvre.

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

Cette catégorie élargit l'ancien risque des « composants vulnérables et obsolètes » à toute la chaîne d'approvisionnement logicielle : bibliothèques tierces, images de base, outillage de build, registres de paquets et pipelines qui les assemblent. Une dépendance ou une étape de build compromise peut introduire du code malveillant dans votre application avant même qu'elle n'atteigne la production.

Mesure de protection : tenir à jour une nomenclature logicielle (SBOM), figer et vérifier les dépendances, et sécuriser le pipeline de build lui-même, afin que seuls des artefacts revus et dont l'intégrité est vérifiée puissent être promus en production.

A04 : Défaillances cryptographiques

Les défaillances cryptographiques surviennent lorsque des données sensibles — mots de passe, informations de paiement, données de santé, données personnelles relevant du RGPD ou de la loi indienne DPDP — ne sont pas correctement protégées en transit ou au repos. Les causes habituelles sont l'absence de chiffrement, des algorithmes faibles ou obsolètes, des clés codées en dur et une mauvaise gestion des clés.

Mesure de protection : classifier vos données, imposer un chiffrement fort des communications partout, chiffrer les données sensibles au repos avec des algorithmes actuels et gérer les clés dans un service dédié de secrets ou de gestion de clés plutôt que dans le code ou les fichiers de configuration.

A05 : Injection

L'injection se produit lorsqu'une entrée non fiable est interprétée comme une commande ou une requête, permettant à un attaquant de modifier la logique du programme. Injections SQL et NoSQL, injections de commandes système et cross-site scripting relèvent toutes de cette catégorie : l'application mélange données et instructions au lieu de les séparer.

Mesure de protection : utiliser des requêtes paramétrées et des API sûres qui lient les entrées en tant que données, valider les entrées avec des listes d'autorisation strictes et encoder les sorties selon leur contexte, afin que le contenu fourni par l'utilisateur ne puisse jamais être exécuté.

A06 : Conception non sécurisée

La conception non sécurisée est une faille de l'architecture elle-même, et non de l'implémentation. Même un code parfaitement écrit ne peut compenser une mesure de sécurité qui n'a jamais été prévue, comme l'absence de limitation de débit sur un parcours de virement ou un processus de réinitialisation de mot de passe détournable pour prendre le contrôle de comptes.

Mesure de protection : appliquer la modélisation des menaces dès le début, définir les exigences de sécurité et les cas d'abus au même titre que les exigences fonctionnelles, et utiliser des modèles de conception sécurisés pour que les bonnes protections soient présentes dès la conception plutôt qu'ajoutées après coup.

A07 : Défaillances d'authentification

Les défaillances d'authentification permettent aux attaquants de compromettre des identités par une mauvaise gestion des identifiants : mots de passe faibles ou déjà compromis autorisés, absence de protection contre la force brute, jetons de session prévisibles ou mal invalidés et absence d'authentification multifacteur. Résultat : prise de contrôle de comptes et credential stuffing à grande échelle.

Mesure de protection : imposer l'authentification multifacteur, vérifier les mots de passe face aux listes de fuites connues, limiter le débit et surveiller les points d'authentification, et générer, faire tourner et invalider les jetons de session de manière sécurisée côté serveur.

A08 : Défaillances d'intégrité des logiciels et des données

Les défaillances d'intégrité apparaissent lorsque du code ou des données critiques sont considérés comme fiables sans vérifier qu'ils n'ont pas été altérés : mises à jour automatiques non signées, désérialisation non sécurisée d'objets non fiables ou étapes CI/CD qui récupèrent des artefacts sans contrôle d'intégrité. Un attaquant capable de substituer une source de confiance prend le contrôle de l'application.

Mesure de protection : vérifier l'intégrité et la provenance du code, des mises à jour et des données à l'aide de signatures numériques, et ne jamais désérialiser des entrées non fiables sans contrôles de type stricts et validation.

A09 : Défaillances de journalisation et d'alerte

Cette catégorie couvre l'insuffisance de journalisation, de supervision et d'alerte, la raison pour laquelle tant de violations passent inaperçues pendant des mois. Si les échecs d'authentification, les violations de contrôle d'accès et les transactions à forte valeur ne sont pas journalisés et qu'aucune alerte n'est déclenchée, une attaque en cours reste invisible pour les défenseurs.

Mesure de protection : journaliser les événements pertinents pour la sécurité avec assez de contexte pour investiguer, centraliser et protéger ces journaux, et les relier à une alerte en temps réel et à un processus de réponse à incident — une obligation renforcée par l'exigence CERT-In de conservation des journaux en Inde pendant 180 jours.

A10 : Mauvaise gestion des conditions exceptionnelles

L'édition 2025 attire explicitement l'attention sur la manière dont les applications traitent les erreurs et les conditions exceptionnelles. Une mauvaise gestion des erreurs peut divulguer des traces d'exécution, des chemins internes et des détails de configuration aux attaquants, ou faire échouer la logique en mode ouvert, accordant l'accès lorsqu'un contrôle échoue au lieu de le refuser. Dans les deux cas, un cas limite devient un incident de sécurité.

Mesure de protection : échouer de manière sécurisée et fermée, renvoyer des messages d'erreur génériques aux utilisateurs tout en journalisant le détail complet côté serveur, et tester délibérément les entrées exceptionnelles et inattendues, pas seulement le parcours nominal.

Comment IntelligenceX vous accompagne

L'OWASP Top 10 2025 indique où chercher, mais la couverture ne compte que si vos applications sont réellement testées face à cette liste. IntelligenceX évalue chaque catégorie au moyen de prestations à dominante manuelle alignées sur l'OWASP et fournit une remédiation exploitable par les développeurs, une approche adaptée aux acheteurs du Royaume-Uni, des États-Unis, de l'UE et de l'Inde.

Notre test d'intrusion d'applications web éprouve chaque catégorie du Top 10 sur votre application en production, du contrôle d'accès défaillant et de l'injection jusqu'aux défaillances de journalisation et de gestion des exceptions, avec des preuves de concept et un nouveau test de remédiation gratuit. Notre revue de code sécurisé examine le code source lui-même pour détecter les failles cryptographiques, d'injection et d'intégrité que les tests en boîte noire peuvent manquer. Notre modélisation des menaces s'attaque frontalement à A06 Conception non sécurisée, en révélant les protections manquantes avant même qu'elles ne soient codées.

Pour les organisations soumises à la réglementation indienne, ces tests s'articulent directement avec les obligations de sécurité de la loi DPDP et les attentes de CERT-In, de la RBI, du SEBI et de l'IRDAI. Pour être clair sur le périmètre : IntelligenceX conseille, évalue et prépare, et n'est pas actuellement habilité par CERT-In ; nous n'émettons pas de certificats et ne signons pas nous-mêmes les audits réglementaires. Contactez notre équipe pour cadrer une évaluation de vos applications.