OWASP Top 10 2025 : guide complet des vulnérabilités web
L'OWASP (Open Web Application Security Project) Top 10 est la référence mondiale pour la sécurité des applications web. Mis à jour régulièrement par des centaines d'experts, il recense les dix catégories de vulnérabilités les plus critiques et les plus répandues. Ce guide vous explique chaque catégorie, son impact concret et les mesures correctives à mettre en place.
A01 — Contrôle d'accès défaillant
Le contrôle d'accès défaillant est devenu la première vulnérabilité OWASP en 2021, détrônant les injections. Il recouvre toutes les situations où des utilisateurs peuvent agir au-delà de leurs permissions. Les exemples les plus courants : IDOR (Insecure Direct Object Reference) permettant d'accéder aux données d'un autre utilisateur en changeant un ID dans l'URL, violation de principe de moindre privilège (accès admin accordé trop largement), CSRF permettant des actions non souhaitées, et accès à des fonctions d'administration sans authentification adéquate.
Correction : Implémenter des contrôles d'accès côté serveur systématiques (ne jamais faire confiance au client), adopter un modèle de refus par défaut, journaliser les échecs de contrôle d'accès, et effectuer des tests d'autorisation dans chaque sprint de développement.
A02 — Défaillances cryptographiques
Anciennement "Exposition de données sensibles", cette catégorie couvre les failles liées au chiffrement et à la protection des données. Les problèmes fréquents : transmission de données sensibles en clair (HTTP au lieu de HTTPS), utilisation d'algorithmes obsolètes (MD5, SHA1 pour les mots de passe), stockage de mots de passe sans hachage ou avec des algorithmes faibles, clés cryptographiques codées en dur dans le code source, et absence de chiffrement des données au repos.
Correction : Utiliser TLS 1.2/1.3 pour toutes les communications, bcrypt ou Argon2 pour le hachage des mots de passe, AES-256 pour le chiffrement des données sensibles, et un gestionnaire de secrets (Vault, AWS Secrets Manager) pour les clés et secrets applicatifs.
A03 — Injection (SQL, NoSQL, OS, LDAP)
Les injections restent la troisième vulnérabilité la plus critique malgré des années de sensibilisation. Une injection SQL classique se produit lorsqu'une entrée utilisateur non validée est incluse directement dans une requête SQL, permettant à l'attaquant de lire, modifier ou supprimer des données. Les variantes incluent les injections NoSQL (MongoDB), OS command injection, LDAP injection et XPath injection.
Correction : Utiliser systématiquement des requêtes paramétrées ou des ORM, valider et nettoyer toutes les entrées utilisateur, appliquer le principe de moindre privilège sur les comptes de base de données, et utiliser des WAF (Web Application Firewall) comme couche de protection supplémentaire.
A04 à A10 : les autres vulnérabilités critiques
A04 — Design non sécurisé : Failles architecturales qui ne peuvent être corrigées par le seul codage sécurisé. Solution : threat modeling dès la conception, revue d'architecture sécurité.
A05 — Mauvaise configuration de sécurité : Services et frameworks avec configurations par défaut non sécurisées, pages d'erreur verboses révélant des informations sensibles, ports inutiles ouverts. Solution : hardening systématique, Infrastructure as Code avec scanning de sécurité.
A06 — Composants vulnérables et obsolètes : Bibliothèques, frameworks et modules avec des CVE connues non patchées. Solution : SCA (Software Composition Analysis) automatisé dans le pipeline CI/CD, politique de mise à jour des dépendances.
A07 — Échecs d'identification et d'authentification : Mots de passe faibles autorisés, absence de MFA, gestion défaillante des sessions. Solution : MFA obligatoire, politique de mots de passe robuste, rotation des tokens de session.
A08 — Défaillances d'intégrité des données et du logiciel : Désérialisation non sécurisée, pipelines CI/CD compromis, mises à jour logicielles sans vérification d'intégrité. Solution : signatures numériques des artefacts, vérification des dépendances tierces.
A09 — Défaillances de journalisation et de surveillance : Absence de logs sur les événements de sécurité, logs non surveillés, pas d'alertes sur les activités suspectes. Solution : logging centralisé, SIEM, alertes sur les échecs d'authentification répétés.
A10 — SSRF (Server-Side Request Forgery) : L'application effectue des requêtes vers des ressources internes à partir d'URL fournies par l'utilisateur, permettant d'accéder aux services internes non exposés. Solution : valider et filtrer toutes les URL entrantes, désactiver les redirections HTTP, utiliser des listes blanches de domaines autorisés.
Intégrer l'OWASP dans votre cycle de développement
L'OWASP Top 10 doit être intégré dans votre processus SDLC (Software Development Lifecycle) à plusieurs niveaux. En phase de conception : threat modeling STRIDE, revue d'architecture sécurité. En développement : SAST (Static Application Security Testing) automatisé dans l'IDE, formation des développeurs aux failles OWASP. En test : DAST (Dynamic Application Security Testing), pentest applicatif annuel par un prestataire qualifié PASSI. En production : WAF, monitoring des logs applicatifs, bug bounty.
Un audit applicatif basé sur l'OWASP Top 10 prend généralement 5 à 10 jours selon la complexité de l'application. Il produit un rapport détaillé de chaque vulnérabilité identifiée, sa criticité CVSS, une preuve d'exploitation et des recommandations de correction priorisées. C'est le point de départ indispensable pour sécuriser vos applications web.