OWASP Top 10 : corriger les failles les plus courantes
L'OWASP Top 10 est cité dans presque tous les cahiers des charges, rarement transformé en pratiques. Pour chaque catégorie : ce qui se passe, et la correction qui fonctionne.
Presque tous les appels d’offres pour une application web exigent qu’elle soit « conforme à l’OWASP Top 10 ». Peu précisent ce que cela veut dire. Le Top 10 de l’OWASP est une liste de sensibilisation aux risques les plus fréquents pour la sécurité des applications web, pas un référentiel de conformité. Il reste un excellent point de départ, à condition de le traduire en pratiques. Ce guide s’appuie sur l’édition 2021, la plus citée ; l’OWASP a engagé en 2025 sa mise à jour, sans remettre en cause les principes de correction ci-dessous.
Les dix catégories et leur correction
| Catégorie (2021) | Ce qui se passe | Correction qui fonctionne |
|---|---|---|
| A01 Contrôle d’accès défaillant | Un utilisateur accède aux données ou fonctions d’un autre en modifiant un identifiant | Vérifier les droits côté serveur à chaque requête, refuser par défaut |
| A02 Défaillances cryptographiques | Données sensibles en clair, algorithmes obsolètes | Chiffrer en transit et au repos avec des bibliothèques éprouvées, gérer les clés hors du code |
| A03 Injection | Une donnée saisie est interprétée comme une commande (SQL, système, script) | Requêtes paramétrées, échappement selon le contexte, validation des entrées |
| A04 Conception non sécurisée | La faille est dans la logique même (pas de limite de tentatives, parcours contournable) | Modélisation des menaces au stade de la conception |
| A05 Mauvaise configuration | Comptes par défaut, messages d’erreur bavards, services inutiles | Configurations durcies et automatisées, identiques entre environnements |
| A06 Composants vulnérables ou obsolètes | Une bibliothèque tierce contient une faille connue | Inventaire des dépendances, analyse automatique, mises à jour régulières |
| A07 Identification et authentification | Mots de passe faibles acceptés, sessions mal gérées | Authentification multifacteur, gestion des sessions par le cadriciel, limitation des tentatives |
| A08 Intégrité des logiciels et des données | Mise à jour ou dépendance altérée, désérialisation non contrôlée | Signatures et vérification d’intégrité, chaîne de construction protégée |
| A09 Journalisation et surveillance insuffisantes | Une attaque passe inaperçue, faute de traces | Journaliser les événements de sécurité, les centraliser, définir des alertes |
| A10 Falsification de requête côté serveur (SSRF) | Le serveur est amené à appeler une adresse choisie par l’attaquant | Liste d’adresses autorisées, cloisonnement réseau des serveurs applicatifs |
Trois catégories qui méritent une attention particulière
Le contrôle d’accès, premier risque
Dans l’édition 2021, le contrôle d’accès défaillant est passé en tête, parce qu’il a été constaté dans la plus grande proportion d’applications testées. La raison est simple : chaque écran, chaque appel d’interface de programmation doit vérifier les droits, et un seul oubli suffit. La correction tient à une règle de conception : les autorisations sont vérifiées par un mécanisme central côté serveur, jamais seulement par l’interface. Les tests doivent essayer systématiquement d’accéder aux ressources d’un autre utilisateur.
La conception non sécurisée
C’est la catégorie qu’aucun outil automatique ne détecte bien. Un parcours de réinitialisation de mot de passe qui révèle si un compte existe, une fonction de paiement sans limite de montant, un processus qui peut être rejoué : ce ne sont pas des bogues, ce sont des choix. Une demi-journée de modélisation des menaces, au stade de la conception d’une fonction sensible, en évite beaucoup.
Les composants tiers
Une application moderne contient plus de code tiers que de code écrit par l’équipe. L’inventaire des dépendances, leur analyse automatique à chaque construction et une politique de mise à jour sont devenus indispensables. Le règlement européen sur la cyberrésilience, entré en vigueur fin 2024, renforcera ces exigences pour les produits comportant des éléments numériques.
La plupart des failles du Top 10 se corrigent par des choix de conception, pas par des correctifs de dernière minute.
Intégrer ces contrôles au cycle de développement
- Exiger au bon niveau. Dans les spécifications, citer l’ASVS de l’OWASP avec un niveau de vérification adapté à l’application, plutôt que le seul Top 10.
- Concevoir : modélisation des menaces pour les fonctions sensibles (authentification, paiement, données personnelles, administration).
- Développer avec des garde-fous : cadriciels qui gèrent sessions, échappement et requêtes paramétrées ; règles de revue de code incluant la sécurité.
- Automatiser les contrôles : analyse du code, analyse des dépendances, recherche de secrets dans le dépôt, à chaque construction.
- Tester : tests d’autorisation automatisés, analyse dynamique en préproduction, test d’intrusion pour les applications sensibles.
- Surveiller en production : journalisation des événements de sécurité, alertes, procédure de correction des vulnérabilités signalées.
Le Top 10 dit quoi craindre ; l’ASVS dit quoi vérifier ; le cycle de développement dit quand le faire. Exiger les trois dans un marché est plus efficace que de demander une « conformité au Top 10 » qui ne se mesure pas.
Liste de contrôle pour un responsable d’application
- Les autorisations sont-elles vérifiées côté serveur pour chaque ressource ?
- L’inventaire des dépendances est-il à jour et analysé automatiquement ?
- Les comptes d’administration utilisent-ils une authentification multifacteur ?
- Les secrets sont-ils hors du code source ?
- Les événements de sécurité sont-ils journalisés et surveillés ?
- Existe-t-il une procédure pour traiter une vulnérabilité signalée ?
Ces exigences s’inscrivent dans le dispositif de gouvernance de la sécurité ; pour les entités concernées, le dossier NIS 2 précise les obligations de sécurité du développement et de la chaîne d’approvisionnement.
Pour approfondir : Gouvernance & traçabilité · Cybersécurité & conformité
Questions fréquentes
Qu'est-ce que l'OWASP ?
L'Open Worldwide Application Security Project est une fondation à but non lucratif qui publie des ressources ouvertes sur la sécurité des applications, dont le Top 10, l'ASVS et des guides de test.
Le Top 10 suffit-il pour sécuriser une application ?
Non. Il recense les risques les plus fréquents pour sensibiliser. Pour spécifier ou vérifier une application, l'OWASP propose l'ASVS (Application Security Verification Standard), beaucoup plus complet.
Quelle édition du Top 10 utiliser ?
L'édition 2021 reste la référence la plus citée dans les marchés. L'OWASP a engagé en 2025 la publication d'une nouvelle édition ; les principes de correction présentés ici restent valables pour l'une comme pour l'autre.
Faut-il un test d'intrusion avant chaque mise en production ?
Pas forcément. Des contrôles automatisés dans la chaîne de développement et une revue de sécurité des changements importants couvrent l'essentiel ; le test d'intrusion intervient pour les applications sensibles et à intervalles réguliers.