Ce guide vous apprend à utiliser l’OWASP Top 10 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.
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.
| 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 »| # | Catégorie | En une phrase | Exemple concret |
|---|---|---|---|
| A01 | Broken Access Control | Un utilisateur accède à ce qu’il ne devrait pas | Consulter la fiche d’un autre client en changeant un ID dans l’URL |
| A02 | Cryptographic Failures | Des données sensibles circulent ou sont stockées sans protection | Mot de passe stocké en clair dans la base |
| A03 | Injection | L’application exécute du code fourni par l’utilisateur | SQL injection : ' OR 1=1 -- qui vide une table |
| A04 | 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é |
| A05 | Security Misconfiguration | Les paramètres par défaut laissent des portes ouvertes | Interface d’admin accessible sans authentification |
| A06 | Vulnerable Components | Des bibliothèques utilisées contiennent des failles connues | Une dépendance avec une CVE critique non corrigée |
| A07 | Auth & Session Failures | L’authentification ou les sessions sont mal gérées | Session qui ne s’invalide pas après déconnexion |
| A08 | Software Integrity Failures | Les mises à jour ou artefacts ne sont pas vérifiés | Une dépendance npm remplacée par une version malveillante |
| A09 | Logging & Monitoring Failures | Les problèmes de sécurité passent inaperçus | Pas d’alerte lors de 1000 tentatives de connexion en 1 minute |
| A10 | SSRF | L’application fait des requêtes vers des ressources internes pour le compte de l’attaquant | Lire les métadonnées d’instance cloud via une URL contrôlée par l’attaquant |
Prérequis
Section intitulée « Prérequis »- 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.
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 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 ?
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 Crypto Failures | Analyse statique (SAST) | Algorithmes obsolètes dans le code |
| A03 Injection | Analyse statique (SAST) | Concaténation de chaînes dans des requêtes |
| A05 Misconfiguration | Analyse dynamique (DAST) | Headers de sécurité absents, configs par défaut |
| A06 Components | Analyse de composition (SCA) | Dépendances avec CVE au-dessus d’un seuil |
| A09 Logging | Analyse statique (SAST) | Données sensibles dans les logs |
Focus sur A04 — Insecure Design
Section intitulée « Focus sur A04 — Insecure Design »A04 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.
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.
Focus sur A08 — Software Integrity Failures
Section intitulée « Focus sur A08 — Software Integrity Failures »A08 couvre les attaques de supply chain (chaîne d’approvisionnement logicielle) : une dépendance malveillante injectée dans le registre npm, un système de build compromis, une mise à jour non vérifiée.
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.
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.
À retenir
Section intitulée « À retenir »- L’OWASP Top 10 est un outil de communication et de formation, pas un audit.
- A04 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.
- La version 2021 a ajouté A04 Insecure Design et A08 Software Integrity Failures — deux catégories absentes de la version 2017 et directement liées aux enjeux DevSecOps modernes.