Dès qu'on parle de sécurité des applications web, un nom revient : OWASP. Il figure dans les cahiers des charges, les offres d'emploi, les rapports d'audit et les formations. Pourtant, beaucoup de personnes le résument à une liste de dix failles. En réalité, l'OWASP est une communauté qui produit des guides, des standards, des outils et des environnements d'entraînement pour tous ceux qui conçoivent, testent ou protègent des logiciels. Cet article explique ce qu'est l'OWASP, présente son célèbre Top 10 dans son édition 2025, les projets les plus utiles et la manière de s'en servir concrètement.
OWASP : définition et origine
OWASP signifie Open Worldwide Application Security Project (anciennement « Open Web Application Security Project »). C'est une fondation à but non lucratif, dédiée à l'amélioration de la sécurité des logiciels par la collaboration ouverte. Le projet a été lancé le 1er décembre 2001, et l'OWASP Foundation a été constituée aux États-Unis en 2004 (voir la page À propos de l'OWASP).
Ses principes :
- Ouverture : documents, outils et forums sont gratuits et accessibles à tous ;
- Neutralité : l'OWASP n'est pas liée à un éditeur ou à un produit commercial ;
- Communauté : les contenus sont produits par des bénévoles, des chercheurs et des professionnels, et l'organisation compte des centaines de chapitres locaux dans le monde.
À retenir : l'OWASP n'est ni un organisme de certification ni une autorité réglementaire. C'est une communauté qui publie des références libres, largement adoptées par l'industrie.
Le OWASP Top 10 : la référence la plus connue
Le OWASP Top 10 est un document de sensibilisation qui recense les risques de sécurité les plus critiques pour les applications web, établis à partir de données et d'un consensus d'experts. Il est mis à jour périodiquement. L'édition 2025 a été annoncée en novembre 2025 et finalisée début 2026 (voir la page OWASP Top 10:2025).
| Rang | Catégorie | En clair |
|---|---|---|
| A01 | Broken Access Control | Un utilisateur accède à ce qu'il ne devrait pas (données d'autrui, fonctions d'administration) |
| A02 | Security Misconfiguration | Configuration par défaut, services inutiles, paramètres de sécurité mal réglés |
| A03 | Software Supply Chain Failures | Composants, dépendances et chaîne de développement compromis ou vulnérables |
| A04 | Cryptographic Failures | Chiffrement absent, faible ou mal utilisé |
| A05 | Injection | Des données non fiables sont interprétées comme des commandes (SQL, commandes système, etc.) |
| A06 | Insecure Design | Défaut de conception, absence de prise en compte de la sécurité dès le départ |
| A07 | Authentication Failures | Authentification faible, sessions mal gérées |
| A08 | Software or Data Integrity Failures | Mises à jour, données ou pipelines dont l'intégrité n'est pas vérifiée |
| A09 | Security Logging and Alerting Failures | Journalisation et alertes insuffisantes pour détecter une attaque |
| A10 | Mishandling of Exceptional Conditions | Erreurs et cas anormaux mal gérés, comportements imprévus |
Selon les analyses publiées sur cette édition, le contrôle d'accès défaillant reste en tête du classement, la catégorie sur les composants vulnérables s'est élargie à l'ensemble de la chaîne d'approvisionnement logicielle, et une nouvelle catégorie sur la gestion des conditions exceptionnelles est apparue.
Ce que le Top 10 n'est pas
- Ce n'est pas une liste exhaustive : une application peut être vulnérable sans qu'aucune des dix catégories ne s'applique exactement.
- Ce n'est pas une checklist de conformité complète : c'est un document de sensibilisation, un point de départ. Pour vérifier une application en profondeur, l'OWASP propose d'autres référentiels, notamment l'ASVS.
- Ce n'est pas un score de gravité : pour évaluer la criticité d'une faille précise, on utilise d'autres outils, comme le score CVSS expliqué dans notre article sur le score CVSS.
Les autres projets OWASP à connaître
L'OWASP gère plusieurs centaines de projets. Voici ceux qui servent le plus au quotidien.
| Projet | À quoi il sert | Pour qui |
|---|---|---|
| ASVS (Application Security Verification Standard) | Liste d'exigences de sécurité vérifiables, organisées par niveaux | Développeurs, auditeurs, donneurs d'ordre |
| Web Security Testing Guide | Méthodologie détaillée de test de sécurité d'une application web | Pentesteurs, auditeurs |
| Cheat Sheet Series | Fiches pratiques par sujet (authentification, gestion de sessions, injection, etc.) | Développeurs |
| ZAP | Outil libre de test de sécurité et de proxy d'interception | Testeurs, développeurs |
| Juice Shop | Application volontairement vulnérable pour s'entraîner | Étudiants, formateurs, équipes de sécurité |
| Dependency-Check | Détection de dépendances vulnérables | Développeurs, DevSecOps |
| SAMM | Modèle de maturité de la sécurité logicielle | Responsables sécurité, direction technique |
L'OWASP publie aussi d'autres « Top 10 » spécialisés : sécurité des API, applications mobiles et applications à base de grands modèles de langage (voir notre article sur l'IA et les fuites de données).
Comment utiliser l'OWASP en pratique
Pour un développeur
- Lire le Top 10 pour comprendre les grandes classes de failles.
- Utiliser les Cheat Sheets pendant le développement : validation des entrées, gestion des mots de passe, sessions.
- Intégrer des contrôles automatiques : analyse des dépendances, tests de sécurité dans l'intégration continue.
- Vérifier les contrôles d'accès à chaque endpoint : c'est la catégorie la plus fréquente.
Pour un auditeur ou un pentesteur
- Cadrer la mission avec l'ASVS et un niveau de vérification cible.
- Suivre le Web Security Testing Guide pour structurer les tests.
- Documenter chaque constat, sa criticité et une recommandation de correction.
Un test sur un système exige toujours une autorisation écrite du propriétaire. Tester sans accord est illégal, même avec un outil libre comme ZAP.
Pour un responsable ou un acheteur
- Demander qu'une application soit évaluée selon l'ASVS ou testée sur les catégories du Top 10.
- Utiliser SAMM pour situer la maturité de l'équipe et bâtir une feuille de route.
- Ne pas se contenter de la mention « conforme OWASP Top 10 » dans un contrat : elle est trop vague, mieux vaut préciser le niveau d'exigence.
Pour se former
- Juice Shop permet de pratiquer dans un environnement légal et sans risque.
- Le site de l'OWASP propose documentation, projets et événements locaux.
- Pour explorer une API, l'outil de test d'API de ForenShield aide à comprendre les échanges entre client et serveur, et la base de vulnérabilités CVE permet de relier des failles connues aux composants utilisés.
Limites et bonnes pratiques
- L'OWASP se concentre sur la couche applicative. Elle ne remplace pas le durcissement du système et de l'infrastructure, abordé dans notre article sur les CIS Benchmarks.
- Un scanner automatique ne trouve pas tout, en particulier les défauts de logique métier et de contrôle d'accès. Un test manuel reste nécessaire.
- Le Top 10 évolue : citez toujours l'édition à laquelle vous vous référez.
- La sécurité se construit dès la conception, pas uniquement en fin de projet.
En résumé
L'OWASP est une fondation ouverte qui met à disposition de tous des références de sécurité applicative. Son Top 10 est la porte d'entrée la plus connue, mais sa vraie richesse tient dans les autres projets : ASVS pour exiger, Web Security Testing Guide pour tester, Cheat Sheets pour développer, ZAP et Juice Shop pour pratiquer. Utilisé avec discernement, il aide les développeurs, les auditeurs et les décideurs à parler le même langage de sécurité.