Ce guide vous apprend à utiliser l'OWASP Top 10:2025 comme outil de travail quotidien, pas comme une liste à cocher lors des audits. À la fin, vous saurez transformer les 10 catégories en programme de sensibilisation pour vos équipes, en critères de code review actionables, et en exigences de quality gates intégrées dans le pipeline CI/CD. Ce guide s'adresse aux développeurs et ingénieurs DevSecOps débutants qui veulent structurer leurs pratiques de sécurité autour d'un référentiel reconnu, mis à jour pour la première fois depuis 2021.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre les 10 catégories de l'OWASP Top 10:2025 et ce qui a changé depuis l'édition 2021
- Utiliser le référentiel pour bâtir un programme de sensibilisation des développeurs
- Traduire chaque catégorie en critères de code review concrets et actionnables
- Définir des quality gates CI/CD calibrées par sévérité, sans bloquer inutilement les équipes
- Distinguer ce que les outils automatiques détectent de ce qui nécessite du threat modeling
Qu'est-ce que l'OWASP Top 10 ?
Section intitulée « Qu'est-ce que l'OWASP Top 10 ? »OWASP (Open Web Application Security Project, prononcé "o-was-p") est une organisation à but non lucratif qui documente les risques de sécurité les plus courants dans les applications web. Son Top 10 est la liste des dix catégories de vulnérabilités les plus répandues et les plus exploitées, mise à jour tous les trois à quatre ans.
C'est un peu comme le bilan de santé annuel des applications web : il ne liste pas toutes les maladies possibles, mais il identifie les dix causes les plus fréquentes de décès applicatif.
L'édition 2025 a été présentée en novembre 2025 lors de l'OWASP Global AppSec DC, puis publiée dans sa version finale en janvier 2026 : c'est la première mise à jour majeure depuis 2021. Huit catégories sont désormais choisies à partir de données empiriques issues de tests réels sur plus de 2,8 millions d'applications et de l'analyse de plus de 175 000 CVE (identifiants de vulnérabilités connues), tandis que deux catégories restantes émergent d'une enquête auprès de la communauté de praticiens, pour capter des risques que les outils automatiques ne détectent pas encore bien.
| Ce que l'OWASP Top 10 est | Ce que l'OWASP Top 10 n'est pas |
|---|---|
| Un référentiel de risques commun | Un standard de certification |
| Un vocabulaire partagé entre devs et sécu | Une liste exhaustive de toutes les vulnérabilités |
| Un outil de sensibilisation et de formation | Une checklist suffisante pour un audit complet |
| Un guide pour prioriser les efforts de sécurité | Un remplacement pour le threat modeling |
Les 10 catégories expliquées simplement
Section intitulée « Les 10 catégories expliquées simplement »Chaque catégorie de l'OWASP Top 10 regroupe plusieurs CWE (Common Weakness Enumeration, des identifiants de types de faiblesses logicielles) derrière une étiquette compréhensible par des non-spécialistes. Le tableau ci-dessous donne, pour chacune, une explication en une phrase et un exemple concret pour ancrer le concept.
| # | Catégorie | En une phrase | Exemple concret |
|---|---|---|---|
| A01 | Broken Access Control | Un utilisateur accède à ce qu'il ne devrait pas (inclut désormais le SSRF) | Consulter la fiche d'un autre client en changeant un ID dans l'URL, ou forcer le serveur à interroger une ressource interne via une URL contrôlée par l'attaquant |
| A02 | Security Misconfiguration | Les paramètres par défaut laissent des portes ouvertes | Interface d'admin accessible sans authentification |
| A03 | Software Supply Chain Failures | Une dépendance, un système de build ou un canal de distribution est compromis | Une dépendance npm remplacée par une version malveillante |
| A04 | Cryptographic Failures | Des données sensibles circulent ou sont stockées sans protection | Mot de passe stocké en clair dans la base |
| A05 | Injection | L'application exécute du code fourni par l'utilisateur | SQL injection : ' OR 1=1 -- qui vide une table |
| A06 | Insecure Design | La fonctionnalité est mal conçue, pas seulement mal codée | Un flux de reset de mot de passe qui révèle si un email est enregistré |
| A07 | Authentication Failures | L'authentification ou les sessions sont mal gérées | Session qui ne s'invalide pas après déconnexion |
| A08 | Software or Data Integrity Failures | Les mises à jour, artefacts ou données ne sont pas vérifiés | Un pipeline qui déploie un artefact sans vérifier sa signature |
| A09 | Security Logging & Alerting Failures | Les incidents de sécurité passent inaperçus faute d'alerte | 1000 tentatives de connexion échouées en une minute sans déclencher d'alerte |
| A10 | Mishandling of Exceptional Conditions | Une erreur ou un cas limite ouvre une brèche au lieu de bloquer | Un service de paiement qui laisse passer la transaction quand la validation échoue en timeout (fail open) |
Prérequis
Section intitulée « Prérequis »Ce guide se concentre sur l'usage pratique de l'OWASP Top 10, pas sur l'explication de HTTP, des sessions ou des concepts DevSecOps depuis zéro. Si ces bases ne sont pas encore acquises, commencez par les ressources ci-dessous : elles installent le vocabulaire commun sur lequel s'appuie tout le reste de la page.
- Notions de développement web (HTTP, sessions, authentification)
- Connaître les concepts de base du DevSecOps
Comment utiliser l'OWASP Top 10 en DevSecOps
Section intitulée « Comment utiliser l'OWASP Top 10 en DevSecOps »L'OWASP Top 10 n'est utile que si on l'intègre dans des pratiques concrètes. Voici les trois usages les plus efficaces, du plus pédagogique au plus automatisé.
Usage 1 : sensibiliser les développeurs
Section intitulée « Usage 1 : sensibiliser les développeurs »L'OWASP Top 10 est un excellent outil de formation initiale. Chaque catégorie peut faire l'objet d'un atelier de 45 minutes avec un exemple exploitable.
Structure d'un atelier par catégorie :
-
Montrez la vulnérabilité (10 min) : un exemple de code vulnérable dans le langage de l'équipe. Des applications intentionnellement vulnérables comme OWASP WebGoat existent pour cet usage : elles permettent d'explorer les failles dans un environnement sûr et légal.
-
Exploitez-la (10 min) : montrez comment l'attaquant exploite la faille. Rien ne marque les esprits autant qu'une démonstration réelle d'exploitation.
-
Corrigez-la (10 min) : la version sécurisée du même code. Expliquez pourquoi la correction fonctionne, pas seulement comment.
-
Montrez la détection automatique (5 min) : est-ce qu'un analyseur de code statique (SAST, pour Static Application Security Testing) détecte cette faille ? Si oui, comment activer la règle. Si non, pourquoi.
-
Discussion libre (10 min) : "Avez-vous déjà vu ce pattern dans notre codebase ?"
Un programme de 10 ateliers (un par catégorie) représente 5 heures de formation sur 10 semaines, un investissement raisonnable pour une équipe de 5 à 15 développeurs.
Usage 2 : structurer la code review
Section intitulée « Usage 2 : structurer la code review »L'OWASP Top 10 se traduit en questions concrètes à poser lors de la revue d'une pull request :
Questions à poser :
- Chaque endpoint vérifie-t-il l'autorisation côté serveur (pas seulement côté client) ?
- Les ressources sont-elles accédées par propriété vérifiée, pas seulement par ID ?
- Les endpoints sensibles sont-ils protégés par des rôles stricts ?
Pattern dangereux, IDOR (Insecure Direct Object Reference) :
# ❌ L'utilisateur 42 peut accéder au profil 99@app.get("/users/{user_id}/profile")def get_profile(user_id: int): return db.get_user(user_id) # Aucune vérification de propriété
# ✅ Vérification de propriété systématique@app.get("/users/{user_id}/profile")def get_profile(user_id: int, current_user: User = Depends(get_current_user)): if current_user.id != user_id and not current_user.is_admin: raise HTTPException(status_code=403) return db.get_user(user_id)Questions à poser :
- Les requêtes SQL utilisent-elles des paramètres liés (jamais de concaténation de chaînes) ?
- Les données utilisateur sont-elles validées et échappées avant d'être utilisées dans des requêtes ou du rendu HTML ?
- Les commandes système construites dynamiquement évitent-elles l'entrée utilisateur non contrôlée ?
Pattern dangereux, injection SQL :
# ❌ Injection SQL possiblequery = f"SELECT * FROM users WHERE name = '{user_input}'"db.execute(query)
# ✅ Requête paramétrée : l'input est traité comme donnée, pas comme codequery = "SELECT * FROM users WHERE name = ?"db.execute(query, (user_input,))Questions à poser :
- Les données PII (données personnelles identifiables) sont-elles chiffrées au repos et en transit ?
- Des algorithmes obsolètes sont-ils utilisés ? (MD5, SHA1, DES et RC4 sont considérés comme cassés)
- Les clés ou secrets sont-ils présents directement dans le code source ?
- TLS (le protocole qui sécurise HTTPS) est-il forcé, même pour les communications internes ?
Questions à poser :
- Le fichier de dépendances (
package.json,requirements.txt,go.mod…) a-t-il de nouvelles entrées ? - Ces nouvelles dépendances ont-elles été vérifiées (vulnérabilités connues, maintenance active, popularité) ?
- Les versions sont-elles verrouillées pour éviter les mises à jour automatiques non contrôlées ?
- Le pipeline de build lui-même (runners, registres, artefacts intermédiaires) est-il isolé et audité ?
Usage 3 : définir les quality gates
Section intitulée « Usage 3 : définir les quality gates »Une quality gate (seuil de qualité) est une condition bloquante dans le pipeline CI/CD : si la condition n'est pas remplie, le code ne peut pas être fusionné ou déployé.
Chaque catégorie OWASP se traduit en type d'analyse automatisable :
| Catégorie | Type d'analyse | Ce qu'elle cherche |
|---|---|---|
| A01 Access Control | Tests d'intégration | Appels non authentifiés qui réussissent |
| A02 Misconfiguration | Analyse dynamique (DAST) | Headers de sécurité absents, configs par défaut |
| A03 Supply Chain | Analyse de composition (SCA) | Dépendances avec CVE au-dessus d'un seuil |
| A04 Crypto Failures | Analyse statique (SAST) | Algorithmes obsolètes dans le code |
| A05 Injection | Analyse statique (SAST) | Concaténation de chaînes dans des requêtes |
| A09 Logging & Alerting | Analyse statique (SAST) | Données sensibles dans les logs |
Focus sur A06 : Insecure Design
Section intitulée « Focus sur A06 : Insecure Design »A06 est la catégorie la plus difficile à détecter automatiquement. Elle concerne les vulnérabilités qui viennent de mauvaises décisions de conception, pas de bugs dans le code : le code peut être parfaitement écrit et malgré tout exposer une faille structurelle.
Exemples concrets :
- Un système de reset de mot de passe qui indique "Cet email n'est pas enregistré", l'attaquant peut ainsi valider l'existence d'un compte
- Une API qui retourne tous les champs d'un objet alors que le client n'en utilise que deux, sur-exposition de données
- Un flux de paiement qui vérifie le montant uniquement côté front-end, validation côté serveur absente
- Un système multi-tenant qui partage des ressources sans isolation stricte entre clients
Aucun scanner ne peut détecter qu'une fonctionnalité est intrinsèquement mal conçue. C'est précisément le domaine du threat modeling : une réflexion structurée, menée avant d'écrire la première ligne de code, sur les façons dont un attaquant pourrait détourner la fonctionnalité prévue.
Focus sur A03 : Software Supply Chain Failures
Section intitulée « Focus sur A03 : Software Supply Chain Failures »A03 est l'une des deux catégories inédites de l'édition 2025. Elle regroupe et étend l'ancienne catégorie 2021 sur les composants vulnérables, en couvrant désormais l'ensemble de la chaîne : dépendances logicielles, systèmes de build et infrastructure de distribution. C'est une attaque de supply chain (chaîne d'approvisionnement logicielle) : une dépendance malveillante injectée dans un registre public, un système de build compromis, ou une mise à jour non vérifiée.
Fait notable relevé par les analyses de l'édition 2025 : cette catégorie affiche le moins d'occurrences détectées dans les tests automatisés, mais les scores d'impact et d'exploitation les plus élevés de tout le référentiel. Autrement dit, ces incidents sont rares mais dévastateurs quand ils surviennent.
Quelques incidents réels pour illustrer la menace :
- event-stream (npm, 2018) : une dépendance populaire modifiée pour voler des crypto-monnaies
- SolarWinds (2020) : le système de build lui-même compromis pour intégrer un backdoor
- Log4Shell (2021) : une bibliothèque de journalisation omniprésente avec exécution de code à distance
Les mitigations passent par la génération de SBOM (Software Bill of Materials, liste exhaustive des composants de votre logiciel, l'équivalent des ingrédients sur un emballage alimentaire), la signature des artefacts, et la vérification de la provenance des builds.
À ne pas confondre : A08 Software or Data Integrity Failures reste une catégorie distincte en 2025, plus étroite. Elle couvre les défauts d'intégrité au moment du déploiement ou de l'exécution (désérialisation non sécurisée, artefact déployé sans vérification de signature, pipeline qui saute une étape de contrôle), là où A03 couvre l'origine et le transport des composants eux-mêmes.
Pièges courants
Section intitulée « Pièges courants »Utiliser l'OWASP Top 10 comme équivalent d'un audit : le Top 10 couvre les risques les plus fréquents, pas tous les risques. Un pentest ou un audit de sécurité complet reste nécessaire.
Considérer que couvrir le Top 10 suffit : une application peut ne présenter aucune des 10 catégories et quand même avoir des vulnérabilités spécifiques à son domaine métier.
Laisser la sécurité uniquement à l'équipe sécu : l'OWASP Top 10 est efficace précisément parce qu'il donne aux développeurs un vocabulaire et des patterns qu'ils peuvent identifier eux-mêmes, sans attendre une revue externe.
Bloquer tous les findings sans distinction : une quality gate trop stricte qui génère trop de faux positifs sera contournée ou désactivée. Calibrez les seuils progressivement.
Confondre les numérotations 2021 et 2025 : l'A04 Insecure Design de 2021 est devenu A06 en 2025, et l'ancienne A06 Vulnerable Components a été absorbée par la nouvelle A03 Software Supply Chain Failures. Précisez toujours l'édition citée dans votre documentation interne pour éviter les malentendus entre équipes.
À retenir
Section intitulée « À retenir »- L'OWASP Top 10 est un outil de communication et de formation, pas un audit.
- L'édition 2025 (version finale de janvier 2026, après une présentation en novembre 2025) est la première mise à jour majeure depuis 2021 : elle introduit deux catégories inédites, A03 Software Supply Chain Failures et A10 Mishandling of Exceptional Conditions.
- Le SSRF, autonome en 2021, est désormais absorbé dans A01 Broken Access Control.
- A02 Security Misconfiguration est monté de la 5e à la 2e place, un signal fort sur les risques liés au cloud et aux déploiements.
- A06 Insecure Design et A01 Broken Access Control ne peuvent pas être couverts uniquement par des outils automatiques : ils nécessitent du threat modeling et des tests manuels ciblés.
- Les quality gates basées sur l'OWASP doivent être calibrées par sévérité : tout bloquer tue l'adhésion des équipes.
- Un programme de sensibilisation en 10 ateliers (un par catégorie) est réaliste sur 10 semaines et produit des résultats mesurables.