- Création
- 2001 par Mark Curphey, fondation à but non lucratif
- Siège
- USA (Maryland) + entité européenne
- Modèle
- Communautaire, bénévole, licences libres, ~250 chapitres locaux dans le monde
- Projet phare
- OWASP Top 10 — référence mondiale depuis 2003
- Financement
- Cotisations de membres corporate, dons, conférences
01 — DéfinitionQu'est-ce qu'OWASP ?
Source officielle : site officiel OWASP.
Pour un panorama complet des failles applicatives (Top 10 OWASP, API Security, LLM Top 10, prévention DevSecOps, bug bounty), voir notre guide OWASP & failles applicatives.
OWASP (Open Worldwide Application Security Project, anciennement Open Web Application Security Project) est une fondation à but non lucratif créée en 2001 par Mark Curphey, dédiée à l'amélioration de la sécurité des logiciels.
OWASP développe gratuitement et publie sous licences libres : outils de test, méthodologies de vérification, référentiels de risques, guides pratiques, supports de formation, applications pédagogiques. Le tout utilisé mondialement par développeurs, auditeurs sécurité, RSSI, architectes, pentesters.
Mission
« Rendre visible la sécurité des logiciels, pour que les individus et les organisations puissent prendre des décisions éclairées ». Traduction pratique : tout ce qu'OWASP produit est gratuit, auditable, réutilisable, y compris en contexte commercial.
Organisation
- Fondation OWASP (501(c)(3) US) : entité légale centrale, basée dans le Maryland (USA).
- OWASP Foundation Europe : entité européenne (Belgique).
- Conseil d'administration : élu par les membres.
- Chapitres locaux : ~250 dans le monde, y compris plusieurs en France (OWASP Paris, OWASP Lyon, OWASP Toulouse, OWASP Lille, OWASP Genève, OWASP Luxembourg).
- Projets : chacun piloté par une équipe de bénévoles, classés en niveaux (Flagship, Lab, Incubator) selon maturité.
- Conférences : Global AppSec US, EU, APAC, événements régionaux.
Modèle de financement
OWASP se finance principalement par :
- Cotisations corporate : membres Gold, Silver, Bronze (Microsoft, Google, Adobe, Salesforce, Contrast Security, Veracode, GitHub, Snyk, etc.).
- Dons individuels : ~3 000 membres individuels payants.
- Conférences : sponsoring et billetterie.
- Subventions ponctuelles : notamment pour projets spécifiques.
Les membres corporate contribuent financièrement mais n'influencent pas la direction technique — modèle comparable à la Fondation Linux ou Apache Foundation. Budget annuel : quelques millions USD.
Positionnement dans l'écosystème
OWASP est la référence communautaire de l'AppSec, complémentaire de :
- NIST : référentiels américains institutionnels.
- ANSSI : référentiels français, qualifications.
- MITRE : CVE, CWE, ATT&CK.
- ENISA : agence européenne cybersécurité.
- SANS Institute : formation et certifications.
OWASP se distingue par son caractère communautaire et gratuit — les autres référentiels sont souvent institutionnels ou payants.
OWASP est à la sécurité applicative ce que Wikipédia est à l'encyclopédie : une construction collective, libre, imparfaite, mais largement indépassable. Pas un développeur web sérieux qui n'ait croisé le Top 10 au moins une fois.
02 — Top 10Le classement phare
L'OWASP Top 10 classe les 10 risques applicatifs web les plus critiques. Publié tous les 3-4 ans depuis 2003 : 2003, 2004, 2007, 2010, 2013, 2017, 2021. Une version 2025 est annoncée pour publication mi-2026.
Méthodologie
Le Top 10 combine :
- Analyse quantitative : données issues de scanners, pentests, bug bounty programs sur centaines de milliers d'applications.
- Enquête communautaire : sondage auprès des professionnels AppSec sur les risques émergents.
- Critères : exploitabilité, prévalence, détectabilité, impact technique et business.
Top 10 OWASP 2021 — version en vigueur
A01 — Broken Access Control (Contrôle d'accès défaillant)
#1 du classement, monté de la 5e place en 2017. Regroupe les défauts qui permettent aux utilisateurs d'accéder à des ressources ou actions qui leur sont interdites. Exemples : IDOR (Insecure Direct Object Reference, changer un ID dans l'URL pour voir les données d'un autre utilisateur), élévation de privilèges, contournement de restrictions, CORS mal configuré.
A02 — Cryptographic Failures (Défaillances cryptographiques)
Anciennement « Sensitive Data Exposure ». Renommé pour mieux refléter la cause racine. Inclut : absence de chiffrement des données sensibles au repos ou en transit, utilisation d'algorithmes obsolètes (MD5, SHA-1, DES), clés faibles, mauvaise gestion des certificats, absence de HTTPS.
A03 — Injection
Fusion de l'historique SQL injection et du Cross-Site Scripting (XSS) depuis 2021. Englobe toutes les injections où des données non fiables sont interprétées comme commandes : SQL injection, NoSQL injection, commande OS, LDAP, XPath, XSS, SSTI (Server-Side Template Injection).
A04 — Insecure Design (Conception non sécurisée)
Nouvelle catégorie 2021. Met en lumière que certains défauts ne sont pas des bugs d'implémentation mais des problèmes de conception : absence de threat modeling, architecture sans contrôle de sécurité appropriée, logique métier vulnérable par design.
A05 — Security Misconfiguration
Configurations par défaut dangereuses, permissions excessives, messages d'erreur révélant la stack, features de debug en production, headers de sécurité absents. Classique très présent dans les audits.
A06 — Vulnerable and Outdated Components
Utilisation de bibliothèques, frameworks, serveurs avec des vulnérabilités connues (CVE). Cas emblématique : Log4Shell en décembre 2021. Remédiation via SBOM et Dependency-Check.
A07 — Identification and Authentication Failures
Anciennement « Broken Authentication ». Gestion défaillante des sessions, mots de passe faibles acceptés, absence de MFA, attaques de credential stuffing facilitées, énumération d'utilisateurs.
A08 — Software and Data Integrity Failures
Nouvelle catégorie 2021 en réponse aux attaques supply chain (SolarWinds, Codecov). Défaillances de l'intégrité des dépendances, mises à jour non vérifiées, CI/CD non sécurisée, désérialisation non sécurisée.
A09 — Security Logging and Monitoring Failures
Absence ou insuffisance de logs de sécurité, non-transmission au SIEM, alertes non configurées. Prolonge le temps de détection des incidents (moyenne observée : ~200 jours pour une intrusion détectée, selon IBM Cost of a Data Breach).
A10 — Server-Side Request Forgery (SSRF)
Nouvelle catégorie 2021. Le serveur est manipulé pour émettre des requêtes vers des cibles non prévues — endpoints internes, metadata cloud (IMDS AWS). Cas emblématique : Capital One 2019, fuite de 100+ millions de dossiers via SSRF sur une instance EC2.
Ce qui a changé entre 2017 et 2021
- Broken Access Control : 5 → 1 (priorité majeure).
- Cryptographic Failures : renommé, 3 → 2.
- XSS fusionné dans Injection.
- 3 nouvelles catégories : Insecure Design, Software and Data Integrity Failures, SSRF.
- Disparues : Insecure Deserialization (fondu dans A08), XXE (fondu dans A05).
Top 10 2025 (en préparation)
La version 2025 est annoncée pour 2026, avec les tendances observées depuis 2021 : focus accru sur les APIs, intégration des risques liés à l'IA/LLM, renforcement des aspects supply chain post-XZ Utils 2024. Pas encore publiée fin avril 2026 — à ce jour, la version 2021 reste la référence officielle.
03 — API Top 10Le classement dédié aux APIs
Publié séparément depuis 2019, l'OWASP API Security Top 10 couvre les risques spécifiques aux APIs REST, GraphQL, gRPC et équivalents. Dernière version : 2023 (mise à jour majeure de la 2019).
Pourquoi un classement séparé ?
Les APIs ont des caractéristiques propres :
- Pas d'UI — les défauts de logique business sont plus directement exploitables.
- Authentification machine-to-machine souvent différente.
- Découverte d'endpoints non documentés.
- Shadow APIs non inventoriées.
- Autorisation granulaire plus complexe (objet, propriété, fonction).
- Rate limiting et consommation de ressources critiques.
OWASP API Security Top 10 2023
- API01 — Broken Object Level Authorization (BOLA) : risque #1. Changer un ID dans une requête API pour accéder aux données d'un autre utilisateur.
- API02 — Broken Authentication : authentification faible ou contournable, tokens mal gérés.
- API03 — Broken Object Property Level Authorization : exposition de propriétés sensibles, excessive data exposure, mass assignment.
- API04 — Unrestricted Resource Consumption : absence de rate limiting, amplification, brute force facile.
- API05 — Broken Function Level Authorization : endpoints administratifs accessibles à tous.
- API06 — Unrestricted Access to Sensitive Business Flows : abus de workflows métier (achat massif automatisé, scalping).
- API07 — Server-Side Request Forgery (SSRF) : même que Web Top 10.
- API08 — Security Misconfiguration : CORS permissif, TLS mal configuré.
- API09 — Improper Inventory Management : APIs v1 anciennes toujours en ligne, shadow APIs.
- API10 — Unsafe Consumption of APIs : confiance excessive aux APIs externes consommées.
Voir aussi notre fiche détaillée API security.
Classements annexes
- OWASP Mobile Top 10 (MASVS) : risques applications mobiles.
- OWASP LLM Top 10 : risques IA/LLM, publié 2023, mise à jour 2025.
- OWASP Serverless Top 10 : focus cloud-native.
- OWASP Kubernetes Top 10 : risques K8s.
- OWASP Top 10 CI/CD Security Risks : DevOps/DevSecOps.
04 — ProjetsLes projets majeurs d'OWASP
Standards et méthodologies
ASVS (Application Security Verification Standard)
Référentiel détaillé de 200+ exigences de sécurité pour auditer et concevoir des applications web. Trois niveaux : L1 (basique, tout usage), L2 (applications avec données sensibles), L3 (applications critiques). Utilisé comme checklist d'audit et base de cahier des charges sécurité.
MASVS (Mobile Application Security Verification Standard)
Équivalent ASVS pour le mobile (iOS/Android). Deux niveaux standards, un niveau Résilience contre le reverse-engineering.
SAMM (Software Assurance Maturity Model)
Modèle de maturité pour évaluer et améliorer le programme AppSec d'une organisation. 5 domaines (Governance, Design, Implementation, Verification, Operations), 15 pratiques, 3 niveaux de maturité.
Cheat Sheets
Plus de 100 fiches pratiques ultra-ciblées sur des sujets précis : Authentication, Password Storage, Input Validation, SQL Injection Prevention, XSS Prevention, CSRF Prevention, REST Security, GraphQL, Docker, Kubernetes, LLM. Format concis, actionnable, mis à jour régulièrement. Ressource incontournable pour les développeurs.
Outils open source
OWASP ZAP (Zed Attack Proxy)
Le scanner de vulnérabilités web open source le plus utilisé au monde. Proxy intercepteur + scanner automatique + fuzzer. Utilisé manuellement pour tests pénétration ou intégré en CI/CD pour tests automatisés. Alternative libre à Burp Suite (payant). Fork récent (2024) nommé ZAProxy après tensions gouvernance, mais ZAP OWASP reste actif.
OWASP Dependency-Check
Scanner de composants vulnérables dans les dépendances d'une application. Identifie les CVE connues via la National Vulnerability Database. Intégrable Maven, Gradle, Jenkins, pipelines CI/CD. Concurrent open source des solutions SCA payantes (Snyk, Black Duck, Veracode SCA).
OWASP Dependency-Track
Plateforme complémentaire pour gérer un parc d'applications avec leurs SBOM (CycloneDX). Détection continue des nouvelles CVE affectant les composants utilisés.
OWASP Amass
Outil de reconnaissance et cartographie de surface d'attaque externe. Enumère sous-domaines, adresses IP, certificats, infrastructures associées à une organisation. Utilisé en pentest et threat intel.
OWASP CSRFGuard, AntiSamy, ModSecurity CRS
Bibliothèques et règles pour se protéger :
- CSRFGuard : protection contre le Cross-Site Request Forgery.
- AntiSamy : sanitisation de HTML entrant.
- ModSecurity Core Rule Set (CRS) : règles WAF open source utilisées par ModSecurity, Coraza, Cloudflare, etc.
Applications pédagogiques vulnérables
OWASP Juice Shop
Application web volontairement vulnérable, développée en JavaScript/TypeScript moderne (Node.js, Angular). ~100 défis couvrant tout le Top 10 et plus. Référence pour la formation, les CTFs (Capture The Flag) et les workshops sécurité.
WebGoat
Historique application Java vulnérable pour l'apprentissage. Couvre les risques classiques avec des leçons guidées. Toujours maintenue, plus traditionnelle que Juice Shop.
DVWA, Mutillidae, Hackazon
Autres applications vulnérables de l'écosystème OWASP ou proches, utilisées en formation.
Threat modeling et guides
- OWASP Threat Dragon : outil de threat modeling open source.
- Pythagoras : autre outil de modélisation.
- Application Security Guide for CISOs : guide stratégique pour les RSSI.
- Testing Guide : méthodologie de test manuel approfondie.
- Code Review Guide : méthodologie de revue de code sécurité.
05 — OutilsOWASP ZAP en pratique
Qu'est-ce qu'OWASP ZAP ?
ZAP (Zed Attack Proxy) est le scanner de vulnérabilités web open source le plus utilisé au monde. Développé initialement par Simon Bennetts en 2010, donné à OWASP la même année, devenu projet Flagship. Téléchargements cumulés : plusieurs dizaines de millions.
Modes d'utilisation
Mode proxy intercepteur
Vous configurez votre navigateur pour passer par ZAP en proxy. ZAP voit toutes les requêtes et réponses, vous permet de les modifier à la volée. Usage : exploration manuelle d'une application, tests de logique business, bypass d'authentification.
Mode scan automatique
- Spider : découverte automatique des URLs d'une application.
- Active Scan : envoi de payloads malveillants (injection, XSS, etc.) pour détecter les vulnérabilités.
- Passive Scan : analyse des réponses sans envoi offensif (headers manquants, cookies non sécurisés).
- Fuzzer : test exhaustif de paramètres avec listes de valeurs.
Intégration CI/CD
Via l'API REST de ZAP, GitHub Actions, GitLab CI, Jenkins. Lance un scan à chaque build, bloque la release si des vulnérabilités critiques sont détectées. Composante classique du DevSecOps.
Ce que ZAP détecte
- Injections (SQL, NoSQL, commande, LDAP, XSS).
- Configurations de sécurité faibles : headers manquants (CSP, HSTS, X-Frame-Options), cookies sans flags.
- Gestion de session défaillante.
- Divulgation d'informations sensibles.
- Composants avec CVE connues (intégration avec Dependency-Check).
- SSRF, XXE, open redirects.
- CSRF tokens absents.
Limites de ZAP
- Ne remplace pas un pentester humain : couvre les vulnérabilités techniques classiques, pas les défauts de logique métier complexes.
- Faux positifs : comme tout scanner, génère du bruit. Tri humain nécessaire.
- Authentification complexe : scans sur applications à forte interactivité demandent configuration soignée.
- Applications SPA modernes : JavaScript-heavy, AJAX, WebSocket nécessitent des options avancées.
Alternatives
- Burp Suite (PortSwigger) : leader commercial, Community Edition gratuite limitée, Professional payante très complète. Standard chez les pentesters professionnels.
- Nuclei (ProjectDiscovery) : open source, scanner rapide basé sur templates communautaires.
- Wapiti, Nikto : autres scanners libres plus légers.
06 — UsageOWASP en entreprise
Pourquoi s'appuyer sur OWASP ?
- Gratuit et ouvert : pas de coût de licence, pas de lock-in vendeur.
- Référence universelle : toute l'industrie connaît et respecte OWASP.
- Indépendant : pas de vendor bias dans les recommandations.
- Communautaire : mises à jour en continu par les meilleurs experts mondiaux.
- Reconnaissance réglementaire : cité dans PCI DSS, NIST, ANSSI.
Usages typiques par rôle
Développeurs
- Formation initiale : Top 10 comme base pédagogique.
- Cheat Sheets comme référence rapide pendant le dev.
- Juice Shop pour s'entraîner à identifier et corriger des vulnérabilités.
Équipes DevSecOps
- ZAP en pipeline CI/CD pour DAST automatisé.
- Dependency-Check / Dependency-Track pour SCA.
- ASVS comme référentiel de gates de qualité.
- ModSecurity CRS en protection runtime WAF.
RSSI et Direction Sécurité
- SAMM pour évaluer et améliorer le programme AppSec.
- Top 10 comme référence dans cahiers des charges fournisseurs.
- ASVS dans exigences contractuelles.
- Threat Dragon pour threat modeling d'applications critiques.
Pentesters / Auditeurs
- ZAP + Burp comme outils principaux.
- Testing Guide pour méthodologie d'audit.
- Top 10 comme structure de rapport.
- Amass pour la reconnaissance initiale.
Intégration dans un programme AppSec
Programme AppSec mature basé OWASP :
- Formation annuelle des développeurs sur le Top 10 (obligation PCI DSS 6.2).
- Threat modeling avec Threat Dragon ou équivalent pour les nouvelles features.
- SCA automatisé avec Dependency-Check dans le CI/CD.
- SAST (analyse statique) complémentaire : SonarQube, Semgrep.
- DAST avec ZAP sur environnements de staging.
- Pentest annuel basé sur méthodologie OWASP Testing Guide.
- WAF avec ModSecurity CRS en production.
- Bug bounty complémentaire pour exploits créatifs.
- Audit ASVS pour applications critiques.
Conformité et réglementations
- PCI DSS 4.0 : requirement 6 cite explicitement OWASP comme référence.
- NIST SP 800-53 / 800-218 : références multiples à OWASP.
- ANSSI PASSI : méthodologies d'audit incluent les référentiels OWASP.
- ISO 27001 : OWASP aide à démontrer l'implémentation de contrôles.
- NIS2 : les obligations de gestion des vulnérabilités applicatives s'appuient naturellement sur OWASP.
- DORA : exigences sur tests de sécurité applicative.
Limitations connues
- Focus web et API : moins couvert sur OT/SCADA, embarqué.
- Top 10 = classement général, pas checklist exhaustive.
- Certains projets moins maintenus que d'autres (cycles de vie variables).
- Qualité très variable entre projets Flagship et Incubator.
- Pas de support commercial officiel : autonomie requise.
07 — FAQQuestions fréquentes
OWASP est-il une certification ?
Non, OWASP n'émet pas de certifications individuelles ou d'entreprise. Il produit des référentiels, des outils et de la documentation. Les certifications AppSec reconnues viennent d'autres organismes : SANS (GIAC GWEB, GWAP, GCIH), (ISC)² (CSSLP pour le développement sécurisé), EC-Council (ECSA, CEH), Offensive Security (OSWE, OSCP). Certaines formations et certifications s'appuient sur OWASP mais ne sont pas émises par OWASP. Exception : OWASP propose des « project badges » pour les contributeurs, sans valeur certifiante formelle.
Quel est le lien entre OWASP et les CVE ?
Complémentaires mais distincts. CVE (Common Vulnerabilities and Exposures, MITRE) identifie des vulnérabilités spécifiques dans des produits précis avec un numéro unique (CVE-2021-44228 = Log4Shell). OWASP Top 10 classe des catégories de risques génériques applicables à toute application. Exemple : Log4Shell est une CVE spécifique qui entre dans la catégorie OWASP A06 « Vulnerable and Outdated Components ». Les deux travaillent ensemble : CVE pour l'inventaire précis, OWASP pour la vue stratégique.
Le Top 10 est-il vraiment suffisant ?
Non, et OWASP le dit clairement. Le Top 10 est un point de départ, pas une checklist exhaustive. Il couvre les risques les plus fréquents, mais une application sérieuse doit aussi considérer : spécificités métier (e-commerce = fraude, banque = transactions, santé = HDS), menaces émergentes (IA/LLM, supply chain sophistiquée), contexte réglementaire (PCI DSS, RGPD, HDS), risques hors top 10 (business logic, abuse cases). Pour une couverture complète, combiner Top 10 + ASVS (200+ exigences détaillées) + threat modeling spécifique + pentest régulier.
OWASP publie-t-il en français ?
Partiellement. L'anglais est la langue principale d'OWASP, mais plusieurs documents clés sont traduits en français par la communauté — notamment : Top 10 2021 traduit en français (disponible sur le site OWASP), certaines Cheat Sheets majeures, matériel pédagogique de chapitres francophones (OWASP Paris, Lyon, Montréal). Les conférences francophones (ex. OWASP Paris Meetups) se tiennent en français. Les outils (ZAP) ont des interfaces traduites. Pour la documentation de référence professionnelle, l'anglais reste recommandé car plus à jour.
Pourquoi le renommage « Open Worldwide » en 2023 ?
OWASP a officiellement changé de nom de « Open Web Application Security Project » à « Open Worldwide Application Security Project » en 2023 pour refléter l'élargissement bien au-delà du web : APIs, mobile, cloud, IoT, IA/LLM, serverless. L'acronyme « OWASP » reste identique, ce qui a permis une transition sans rupture pour la communauté. Le nouveau nom reflète aussi la dimension internationale avec chapitres dans plus de 65 pays.
Comment contribuer à OWASP ?
Plusieurs voies ouvertes à tous :
- Contribuer à un projet : code sur GitHub, traductions, relecture, issues.
- Rejoindre un chapitre local : meetups, présentations.
- Parler à une conférence : Global AppSec et événements régionaux ouverts aux soumissions.
- Devenir membre individuel : 50 USD/an, soutient la fondation.
- Proposer un nouveau projet : si besoin non couvert.
- Sponsor corporate : niveau Gold/Silver/Bronze pour entreprises.
L'accès est délibérément ouvert et meritocratique, pas besoin de diplômes ou de CV particuliers.