OWASP Top 10:2025 — La nouvelle version, catégorie par catégorie

Ce qui a changé et pourquoi c'est important#

Le classement 2025 reflète quatre années de télémétrie et un net déplacement de la préoccupation de l'industrie : moins de bugs ponctuels au niveau du code, davantage de défaillances systémiques dans la façon dont les logiciels sont construits, distribués et exploités.

L'OWASP a analysé environ 175 000 correspondances CVE→CWE réparties sur 589 CWE distincts (contre ~400 en 2021) couvrant approximativement 2,8 millions d'applications testées. Huit catégories sont issues directement de ce jeu de données ; deux — Défaillances de la Chaîne d'Approvisionnement Logicielle et Mauvaise Gestion des Conditions Exceptionnelles — ont été promues par sondage, où 50 % des répondants ont classé la chaîne d'approvisionnement comme préoccupation n°1.

Deux conséquences pratiques :

1. Les référentiels de conformité auront du retard. La plupart des correspondances SOC 2, PCI DSS et ISO 27001 référencent encore 2021. Prévoyez une fenêtre de transition de 6 à 18 mois.
2. L'outillage de détection est partiellement en retard. Les scanners SAST et DAST dont les règles étaient alignées sur 2021 doivent être re-mappés — en particulier pour la chaîne d'approvisionnement (A03) et les conditions exceptionnelles (A10), qui n'avaient pas de catégorie de premier rang auparavant.

A01:2025 — Contrôle d'Accès Défaillant#

Changement de position : inchangé à #1. 40 CWE rattachés.

Les défaillances de contrôle d'accès restent la classe de vulnérabilité la plus répandue dans les applications testées. Plus gros changement structurel en 2025 : le SSRF (CWE-918) est désormais intégré à A01 au lieu d'être une catégorie distincte. Le raisonnement de l'OWASP : le SSRF est fondamentalement une défaillance d'autorisation côté serveur — l'application effectue une requête que l'utilisateur ne devrait pas pouvoir lui imposer.

Manifestations courantes :

• IDOR et BOLA (défauts d'autorisation au niveau de l'objet)
• Absence de contrôle au niveau fonction sur les endpoints POST/PUT/DELETE
• Manipulation de JWT ou de cookies pour élévation de privilèges
• Mauvaise configuration CORS autorisant des origines non prévues
• Manipulation de paramètres URL et forced browsing
• SSRF atteignant les endpoints de métadonnées cloud (IMDSv1, métadonnées GCP/Azure)

Correctifs. Refus par défaut. Centralisez l'autorisation dans une couche d'application unique. Validez la propriété des enregistrements côté serveur à chaque requête. Désactivez IMDSv1, imposez IMDSv2 avec hop limit 1 sur AWS.

Approfondir : /learn/idor, /learn/idor-vertical, /learn/ssrf-cloud-metadata.

A02:2025 — Mauvaise Configuration de Sécurité#

Changement de position : monte de #5 (2021) à #2. 16 CWE rattachés.

Plus grosse progression du classement. L'OWASP indique que 100 % des applications testées présentaient au moins une forme de mauvaise configuration, avec un taux d'incidence moyen de 3,00 % par CWE. La promotion reflète la complexité croissante des stacks modernes — Kubernetes, service mesh, IaC, multi-cloud — et le coût élevé d'une erreur sur la moindre couche.

Manifestations courantes :

• Identifiants par défaut laissés en place (consoles d'admin, brokers de messages, bases de données)
• Buckets S3/GCS publics et IAM trop permissif
• Messages d'erreur verbeux exposant traces de pile et versions de framework
• En-têtes de sécurité manquants (CSP, HSTS, X-Content-Type-Options)
• Services inutiles et endpoints de debug accessibles en production
• Durcissement incohérent entre environnements

Correctifs. Mettez en place un processus de durcissement reproductible avec détection automatisée des dérives (CIS Benchmarks, Open Policy Agent, conftest). Centralisez la gestion des erreurs. Utilisez des identifiants fédérés à courte durée plutôt que des secrets longue durée intégrés dans les images ou fichiers de config.

A03:2025 — Défaillances de la Chaîne d'Approvisionnement Logicielle (NOUVEAU)#

Changement de position : nouvelle catégorie à #3. Expansion de l'A06:2021 "Composants Vulnérables et Obsolètes". 5 CWE rattachés.

Le changement phare de 2025. L'ancienne catégorie était étroite — "votre bibliothèque est-elle obsolète ?" La nouvelle couvre tout le cycle de vie : dépendances, dépendances transitives, pipelines de build, secrets CI/CD, registres de paquets, infrastructure de signature de code et canaux de distribution.

Classée #1 dans le sondage communautaire par exactement 50 % des répondants. Malgré le taux d'occurrence le plus faible du jeu de données de test, l'OWASP note qu'A03 a l'impact moyen pondéré le plus élevé de toutes les catégories 2025 — quand les attaques sur la chaîne d'approvisionnement réussissent, elles tendent à être catastrophiques.

Incidents marquants qui ont façonné le cadrage 2025 :

• SolarWinds (2019) — éditeur compromis ayant atteint ~18 000 organisations
• Backdoor XZ Utils (CVE-2024-3094) — opération d'ingénierie sociale pluriannuelle visant un mainteneur OSS ; un backdoor sshd a failli atterrir dans Debian/Fedora stable
• Bybit (2025) — compromission de la chaîne d'approvisionnement de l'outillage wallet, ~1,5 milliard $ de vol
• Shai-Hulud (2025) — premier ver npm auto-propagateur ; a touché 500+ versions de paquets avant retrait, en exfiltrant des tokens npm via des scripts post-install pour republier des versions malveillantes

Manifestations courantes :

• Mises à jour de paquets non signées et absence de vérification d'intégrité
• Pipelines CI/CD avec plus de privilèges que les systèmes qu'ils déploient
• Typosquatting et dependency confusion dans les registres de paquets
• Tokens de registre longue durée stockés en clair sur les postes développeurs
• Dépendances transitives non tracées, sans SBOM
• Pattern "trust the registry" — pull du tag latest sans pinning de hash

Correctifs. Maintenez un SBOM à jour (CycloneDX ou SPDX). Pinnez les dépendances par hash, pas par plage de versions. Vérifiez les signatures (Sigstore/Cosign pour les conteneurs, npm provenance pour JS, PEP 740 pour Python). Durcissez la CI/CD avec une fédération OIDC à moindre privilège. Déployez en canary. Traitez vos postes développeurs et serveurs de build comme des cibles de production.

A04:2025 — Défaillances Cryptographiques#

Changement de position : descend de deux rangs, de #2 (2021) à #4. 32 CWE rattachés.

Renommée de "Exposition des Données Sensibles" (2017) à "Défaillances Cryptographiques" (2021), la catégorie conserve son nom 2021. La mise à jour 2025 resserre le périmètre sur les faiblesses cryptographiques spécifiques plutôt que sur le concept plus large de "fuite de données".

Manifestations courantes :

• Algorithmes faibles (MD5, SHA-1, DES, RC4) encore en production
• Clés codées en dur dans les dépôts ou images de conteneurs
• IV réutilisés, mode ECB, absence de chiffrement authentifié
• Certificats auto-signés ou non validés acceptés par les clients TLS
• Hachage de mots de passe avec des fonctions rapides (SHA-256, MD5) au lieu de fonctions adaptatives
• Génération pseudo-aléatoire prévisible pour les tokens et identifiants de session

Correctifs. TLS 1.2+ uniquement avec suites à secret persistant (forward secrecy). Argon2id, scrypt, ou PBKDF2-HMAC-SHA-512 pour le hachage de mots de passe. Chiffrement authentifié (AES-GCM, ChaCha20-Poly1305) pour la crypto symétrique. Clés dans des HSM ou KMS, jamais dans le code source. Lancez dès maintenant la planification de votre migration post-quantique — le NIST recommande de transitionner les systèmes critiques d'ici 2030.

Approfondir : /learn/jwt-vulnerabilities, /learn/jwt-weak-secret.

A05:2025 — Injection#

Changement de position : descend de deux rangs, de #3 (2021) à #5. 38 CWE rattachés.

L'injection poursuit son déclin pluri-décennal grâce aux frameworks plus sûrs par défaut (requêtes paramétrées, ORM, échappement automatique React/Vue). Elle reste très impactante quand elle survient — l'OWASP rapporte plus de 14 000 CVE d'injection SQL et plus de 30 000 CVE de XSS dans le jeu de données analysé.

Sous-classes encore observées en production :

• Injection SQL — faible fréquence, fort impact
• Cross-Site Scripting (XSS) — fréquence élevée, impact moindre par instance
• Injection de commandes — fort impact, souvent dans des outils d'admin legacy
• Injection LDAP — de niche mais persistante dans les flux d'authentification d'entreprise
• Injection NoSQL — injection d'opérateurs Mongo, Couchbase
• Injection de langage d'expression — Spring SpEL, OGNL, Thymeleaf
• Injection ORM — HQL Hibernate, requêtes brutes Sequelize

Correctifs. Requêtes paramétrées partout ; si vous ne pouvez pas paramétrer (par exemple ORDER BY dynamique), utilisez une allowlist stricte. Validation d'entrée côté serveur. Combinez SAST + DAST + IAST — chacun attrape une forme différente d'injection. Une fois l'une de ces classes confirmée, scorez-la avec notre calculateur CVSS v4.0 gratuit pour fixer la bonne sévérité de remédiation.

Approfondir : /learn/sqli, /learn/xss, /learn/command-injection, /learn/ssti.

A06:2025 — Conception Non Sécurisée#

Changement de position : descend de deux rangs, de #4 (2021) à #6. Pas de baisse d'importance — ce sont A02 et A03 qui ont poussé vers le haut.

La conception non sécurisée couvre les défaillances architecturales et de processus qui ne peuvent pas être corrigées au niveau du code. Le cadrage 2025 met l'accent sur trois piliers : gestion des exigences et des ressources, méthodologie de conception sécurisée, et cycle de vie de développement sécurisé documenté.

Manifestations courantes :

• Modélisation des menaces absente ou esquivée sur les flux critiques (auth, facturation, RBAC)
• Violations de frontière de confiance (données fournies par le client considérées comme autoritaires)
• Stockage de credentials insuffisamment protégé (CWE-522)
• Téléversement de fichiers sans restriction by design (CWE-434)
• Gestion des privilèges intégrée à la logique métier au lieu d'une couche d'autorisation centrale
• "On ajoutera le rate limiting plus tard" — pattern récurrent en startup en croissance

Correctifs. Modélisez les menaces sur chaque nouvelle fonctionnalité touchant l'auth, l'argent ou les PII. Maintenez une bibliothèque de patterns de conception sécurisée réutilisés par l'équipe. Écrivez des tests unitaires et d'intégration ciblant les cas d'abus, pas seulement les chemins nominaux. Impliquez un professionnel AppSec dans les revues de conception, pas seulement les revues de code.

A07:2025 — Défaillances d'Authentification#

Changement de position : inchangé à #7. Renommé de "Défaillances d'Identification et d'Authentification" (2021) en "Défaillances d'Authentification" — les 36 CWE rattachés concernent majoritairement l'authentification, pas l'identification.

Manifestations courantes :

• Mots de passe et clés API codés en dur (CWE-259, CWE-798)
• Fixation de session (CWE-384)
• Logique d'authentification incorrecte (CWE-287) — typiquement contournements via manipulation d'en-têtes, conditions de course, ou trous logiques
• Contournements de validation de certificat (CWE-297)
• MFA absent ou faible sur les comptes privilégiés
• Identifiants de session prévisibles, pas de rotation après login
• Énumération de compte via différences de timing ou de réponse

Correctifs. MFA sur chaque compte privilégié, idéalement résistant au phishing (FIDO2/WebAuthn). Politiques de mot de passe alignées NIST SP 800-63b — pas de rotation forcée, vérification contre listes de fuites, pas de règles de composition. Gestionnaires de session côté serveur avec ID à haute entropie. Limitez les échecs de login ; verrouillez ou step-up au-delà d'un seuil.

Approfondir : /learn/jwt-alg-none, /learn/session-overview, /learn/csrf.

A08:2025 — Défaillances d'Intégrité des Logiciels ou des Données#

Changement de position : inchangé à #8. Périmètre resserré — la partie chaîne d'approvisionnement est sortie vers A03:2025. A08 se concentre désormais sur la vérification d'intégrité au niveau code et données : validation de signature, désérialisation et intégrité du pipeline CI/CD au sein de votre propre environnement.

Manifestations courantes :

• Inclusion de fonctionnalité depuis une sphère de contrôle non fiable (CWE-829)
• Désérialisation de données non fiables (CWE-502) — Java, .NET, pickle Python, Marshal Ruby
• Mises à jour automatiques sans validation de signature (CWE-494)
• Modification d'attributs d'objet déterminés dynamiquement (CWE-915) — y compris mass assignment
• Chargement de scripts depuis des CDN non fiables sans subresource integrity

Correctifs. Vérifiez les signatures numériques sur chaque artefact exécutable ingéré. Restreignez la désérialisation aux types autorisés — ne désérialisez jamais une entrée non fiable avec pickle.loads, unserialize, ObjectInputStream ou Marshal.load. Hashes de subresource integrity sur chaque script externe. Revue de code obligatoire sur chaque changement touchant la configuration CI/CD.

Approfondir : /learn/mass-assignment.

A09:2025 — Défaillances de Journalisation et d'Alerte de Sécurité#

Changement de position : inchangé à #9. Renommé depuis "Défaillances de Journalisation et de Surveillance" — l'OWASP a voulu insister sur le fait que journaliser sans alerter, c'est juste de la consommation disque coûteuse.

Manifestations courantes :

• Événements à forte valeur (login, échec de login, changement de privilèges, transaction financière) non journalisés
• Journaux sans contexte suffisant pour l'analyse forensique (pas d'ID utilisateur, pas de corrélation de requête)
• Injection dans les logs (CWE-117) permettant altération ou évasion d'alerte
• Données sensibles (mots de passe, tokens, PII) écrites dans les logs (CWE-532)
• Pas d'alerte sur les anomalies d'authentification, les élévations de privilèges ou les patterns d'exfiltration
• Stockage append-only / inviolable absent — les attaquants effacent les logs post-compromission

Correctifs. Définissez en amont le catalogue d'événements pertinents pour la sécurité (succès/échec login, changement de privilèges, enrôlement MFA, réinitialisation de mot de passe, action admin). Centralisez les logs dans un stockage append-only. Alertez sur les patterns, pas seulement les seuils — cinq échecs de login, c'est du bruit ; cinq échecs suivis d'un succès depuis une nouvelle géographie, c'est un signal. Faites des exercices tabletop contre vos playbooks d'alerte.

A10:2025 — Mauvaise Gestion des Conditions Exceptionnelles (NOUVEAU)#

Changement de position : nouvelle catégorie à #10. 24 CWE rattachés. Promue par sondage communautaire.

L'autre nouvelle entrée majeure de 2025. A10 est conceptuellement proche d'A06 (Conception Non Sécurisée) mais se concentre spécifiquement sur ce qui se passe quand quelque chose va mal au runtime : un paramètre manquant, un timeout amont, une entrée malformée, un deadlock de base de données. Failing open, fuite de détails d'erreur, ressources laissées verrouillées, ou perte d'atomicité transactionnelle — tout cela tombe ici.

Manifestations courantes :

• "Failing open" — un contrôle de sécurité lève une exception et le bloc catch renvoie un succès (CWE-636)
• Pages d'erreur verbeuses exposant traces de pile, versions de framework, fragments de requête (CWE-209)
• Déréférencement de pointeur null permettant un DoS (CWE-476)
• Gestion absente d'un paramètre manquant entraînant un crash ou un comportement par défaut activé (CWE-234)
• Transactions multi-étapes interrompues en cours de flux sans rollback — corruption d'état financier
• Fuites de ressources via handles non relâchés dans les chemins d'exception (DoS par épuisement)
• Mauvaise gestion de privilèges insuffisants (CWE-274) — l'opération continue avec des contrôles dégradés

Correctifs. Attrapez les exceptions à l'endroit où elles surviennent, pas dans un catch-all de haut niveau. Failing closed : tout contrôle d'auth/authz/intégrité qui lève doit basculer par défaut sur le refus. Centralisez les réponses d'erreur — renvoyez des messages génériques aux clients, journalisez les détails côté serveur. Utilisez des patterns transactionnels avec rollback explicite. Ajoutez des rate limits, quotas de ressources et timeouts à chaque frontière externe. Surveillez les pics de taux d'erreur ; ils précèdent ou accompagnent souvent les attaques.

Correspondance entre 2025 et 2021#

Recommandations d'adoption#

Pour la plupart des équipes sécurité et engineering, le travail pratique consiste à :

1. Re-mappez votre programme AppSec — mettez à jour les registres de risques internes, les templates de threat modeling et les checklists de tests sécurité pour référencer les catégories 2025. Conservez une grille de correspondance 2021↔2025 pour les audits.
2. Priorisez les contrôles A03 dès maintenant. SBOM, artefacts signés, CI/CD durcie, pinning de hash des dépendances. C'est la catégorie la plus susceptible de produire un incident public en 2026.
3. Auditez vos chemins de gestion d'erreur pour A10. Lancez des revues de modes de défaillance sur les flux auth et facturation en particulier — la plupart des bugs "failing open" observés en production commencent par un try/except qui avale une exception.
4. Mettez à jour vos règles de détection. Les outils SAST et DAST devraient mapper les findings sur A03 et A10 explicitement. Si votre scanner rapporte encore "Composants Vulnérables" ou n'a pas de bucket A10, faites remonter au fournisseur.
5. N'attendez pas la version finale. Les RC OWASP changent rarement de classement. Traitez 2025 comme la norme de travail dès aujourd'hui.

Où se positionne BreachVex#

BreachVex est en pré-lancement, donc nous resterons brefs et honnêtes. Notre pipeline cible les catégories que l'automatisation peut vérifier de manière fiable : A01 (contrôle d'accès), A05 (injection), A02 (mauvaise configuration) et une partie d'A04 (problèmes de protocole cryptographique en bordure de réseau). Pour A03 chaîne d'approvisionnement et A09 alerte, les tests externes automatisés ont une portée limitée — ils nécessitent un accès au pipeline et des données d'observabilité dont nous ne disposons pas en boîte noire.

Attendez-vous à un reporting aligné 2025 dans nos sorties SARIF et PDF au lancement. Les correspondances de catégorie dans nos métadonnées de finding référenceront à la fois 2021 et 2025 pendant la transition.