Le OWASP Top 10 Web est la liste des 10 catégories de vulnérabilités les plus critiques qui peuvent affecter une application web, publiée par la fondation OWASP (Open Worldwide Application Security Project) depuis 2003 et mise à jour tous les 3-4 ans. La version en vigueur en 2026 est le OWASP Top 10 Web 2021 (une version 2025 RC1 est en draft public). Pour le lire vite : chaque catégorie porte un code (A01 à A10), un nom, une idée générale, des exemples concrets et des défenses recommandées. Ce n'est pas une liste exhaustive des failles web — c'est le socle minimum que tout développeur, chef de projet IT, RSSI ou apprenant cybersécurité doit comprendre avant de toucher à une application en production. Cet article explique chaque catégorie avec une analogie du quotidien, un scénario concret, et une défense principale — en français, sans jargon inutile, au niveau d'un développeur junior qui découvre l'AppSec ou d'un chef de projet non cyber qui arbitre les priorités sécurité.
1. Comment lire le OWASP Top 10
Chaque catégorie du Top 10 est notée A01, A02, ..., A10. A pour Application. Le numéro correspond au rang de criticité estimé par OWASP sur la base de trois facteurs : fréquence, impact potentiel, facilité d'exploitation. A01 est la plus répandue et/ou la plus grave ; A10 est importante mais moins prévalente.
La criticité du Top 10 ne se lit pas comme un classement de dangerosité absolue : une A10 (SSRF) bien exploitée peut causer plus de dégâts qu'une A05 (misconfiguration) mineure. Le Top 10 classe par prévalence + risque moyen, pas par « pire scénario imaginable ».
2. Vue d'ensemble : les 10 catégories en un coup d'œil
| Code | Nom OWASP | Idée simple | Exemple quotidien |
|---|---|---|---|
| A01 | Broken Access Control | On accède à ce qu'on ne devrait pas | Lire le dossier médical d'un autre patient |
| A02 | Cryptographic Failures | Les secrets ne sont pas vraiment secrets | Coffre-fort avec une serrure facile à crocheter |
| A03 | Injection | On mélange instruction et donnée | Un cuisinier qui prend une commande comme un ordre |
| A04 | Insecure Design | Le plan est mauvais dès le départ | Plan de maison sans serrure sur la porte d'entrée |
| A05 | Security Misconfiguration | Le produit est bon, l'installation est bancale | Alarme installée mais pas activée |
| A06 | Vulnerable and Outdated Components | Des pièces détachées défectueuses | Pneu rappelé qu'on n'a pas changé |
| A07 | Identification and Authentication Failures | La porte d'entrée est faible | Serrure qui s'ouvre avec un passe-partout |
| A08 | Software and Data Integrity Failures | On fait confiance à ce qu'on ne devrait pas | Coursier qui modifie le colis en route |
| A09 | Security Logging and Monitoring Failures | L'alarme ne sonne pas | Caméra de surveillance éteinte |
| A10 | Server-Side Request Forgery | Le serveur va chercher là où il ne devrait pas | Un majordome qu'on envoie fouiller chez le voisin |
3. Les 3 premières : accès, secrets, injection (A01-A03)
3.1 A01 Broken Access Control — « J'accède à ce que je ne devrais pas »
L'idée simple. L'application vérifie bien que tu es connecté, mais elle ne vérifie pas correctement que tu as le droit d'accéder à la ressource précise que tu demandes. C'est comme un hôtel qui vérifie que tu as une carte d'employé mais pas si cette carte ouvre la chambre 302 ou toutes les chambres.
Un scénario. Tu es connecté sur un site de facturation avec ton compte. Tu cliques sur « Voir ma facture n°42 » et l'URL devient /factures/42. Tu changes 42 en 43 dans la barre d'adresse et tu vois la facture du voisin. Ça s'appelle un IDOR (Insecure Direct Object Reference). L'application a vérifié que tu étais connecté mais pas que la facture 43 t'appartenait.
La défense. Pour chaque ressource demandée, vérifier côté serveur que l'utilisateur connecté a bien le droit d'y accéder. Pas « est-il connecté » mais « a-t-il le droit à cet objet précis ».
Pourquoi c'est la #1. 3,81 % des applications testées présentent une occurrence, soit plus de 318 000 cas documentés. C'est la catégorie la plus répandue.
3.2 A02 Cryptographic Failures — « Mes secrets ne sont pas si secrets »
L'idée simple. Les données sensibles (mots de passe, numéros de carte, données de santé) sont mal protégées. Soit elles ne sont pas chiffrées, soit elles sont chiffrées avec une méthode qui ne protège plus grand-chose en 2026.
Un scénario. Un site stocke les mots de passe hashés en MD5 (un algorithme des années 90, cassé depuis 20 ans). Un attaquant vole la base de données et retrouve les mots de passe originaux en quelques heures grâce à des tables pré-calculées. Autre variante : le site ne force pas HTTPS, donc les mots de passe circulent en clair quand un utilisateur se connecte depuis un WiFi public.
La défense. Utiliser les algorithmes recommandés en 2026 : Argon2id (ou bcrypt en fallback) pour les mots de passe, AES-256-GCM pour le chiffrement symétrique, HTTPS partout avec TLS 1.2 minimum et idéalement TLS 1.3.
3.3 A03 Injection — « Le serveur prend ma donnée pour une instruction »
L'idée simple. L'application mélange ce que tape l'utilisateur (données) avec les commandes qu'elle envoie à la base de données, au système ou à un autre composant. L'attaquant glisse alors une commande malveillante dans un champ prévu pour une donnée.
Un scénario. Sur un formulaire de recherche, je tape : ' OR '1'='1 à la place de mon nom. L'application construit une requête SQL qui devient SELECT * FROM users WHERE name='' OR '1'='1' — condition toujours vraie — et me renvoie la liste complète des utilisateurs. C'est une SQL Injection, la plus célèbre des injections. Variantes : Cross-Site Scripting (XSS) où on injecte du JavaScript, Command Injection où on injecte une commande shell, LDAP Injection, NoSQL Injection.
La défense. Requêtes paramétrées (prepared statements) systématiques — jamais de concaténation d'input utilisateur dans une requête. Les frameworks modernes (Django ORM, Rails ActiveRecord, Spring Data, Laravel Eloquent) le font nativement. Côté XSS : échapper tout ce qu'on affiche dans une page selon le contexte (HTML, attribut, JavaScript, CSS), et utiliser une Content Security Policy (CSP) stricte.
4. Les 3 du milieu : design, config, composants (A04-A06)
4.1 A04 Insecure Design — « Le plan est mauvais dès le départ »
L'idée simple. Contrairement aux catégories précédentes qui sont des bugs de code, celle-ci vise les défauts architecturaux. La faille est dans le schéma de conception, pas dans une ligne de code précise. On peut patcher pendant des années, le problème reste.
Un scénario. Un site d'e-commerce permet à n'importe qui d'acheter un code promo en quantité illimitée, qui se cumule sans limite avec d'autres codes. Résultat : prix final négatif, le site crédite l'acheteur. Ce n'est pas un bug de code, c'est un défaut de conception : personne n'a prévu ce cas dans les règles métier.
La défense. Threat modeling dès la phase de design (méthodologie STRIDE, PASTA, ou LINDDUN pour la vie privée). Lister les menaces possibles avant d'écrire la première ligne de code, prévoir des règles métier défensives (quantité maximale, limite de temps, plafonds, validation croisée).
4.2 A05 Security Misconfiguration — « Le produit est bon, l'installation est bancale »
L'idée simple. Le logiciel ou le framework est sécurisé par défaut, mais l'équipe qui l'a installé a laissé des options dangereuses activées, des mots de passe par défaut, ou des fonctions de debug accessibles en production.
Un scénario. Une application Django est déployée avec DEBUG=True. Un visiteur déclenche une erreur : la page d'erreur affiche la stack trace complète, les variables d'environnement incluant les credentials de la base de données, et une console interactive Python en ligne. Autres exemples classiques : compte admin/admin non changé, fichier .env exposé, interface d'administration /admin accessible publiquement, CORS configuré avec Access-Control-Allow-Origin: *.
La défense. Hardening systématique selon les CIS Benchmarks de la technologie utilisée. Audit de configuration avant mise en production. Headers de sécurité standards : X-Content-Type-Options, X-Frame-Options, Referrer-Policy, CSP, HSTS. Principe deny by default sur toutes les fonctions.
4.3 A06 Vulnerable and Outdated Components — « Des pièces détachées défectueuses »
L'idée simple. Une application moderne est construite à 80-90 % avec des bibliothèques tierces (npm, PyPI, Maven, NuGet). Si l'une de ces bibliothèques a une vulnérabilité connue et qu'on ne l'a pas mise à jour, l'application hérite de cette faille.
Un scénario. En décembre 2021, une vulnérabilité critique a été découverte dans la bibliothèque Java Log4j utilisée par des millions d'applications (CVE-2021-44228, surnommée Log4Shell, score CVSS 10.0 — le maximum). Les organisations qui ne l'ont pas patchée dans les 72 heures ont été massivement exploitées. Autres exemples récents : MOVEit en 2023 (CVE-2023-34362, exploitée par le groupe ransomware Cl0p), xz-utils en mars 2024 (CVE-2024-3094, tentative de backdoor dans la supply chain Linux).
La défense. Maintenir un SBOM (Software Bill of Materials, la liste exhaustive des composants utilisés). Utiliser un outil de SCA (Software Composition Analysis) : Snyk, Dependabot, Renovate, Dependency-Track. Politique de patching avec SLA : < 72 h pour CVSS ≥ 9, < 30 jours pour CVSS ≥ 7.
5. Les suivantes : auth, intégrité, logs (A07-A09)
5.1 A07 Identification and Authentication Failures — « La porte d'entrée est faible »
L'idée simple. Le mécanisme par lequel les utilisateurs prouvent qui ils sont est mal conçu ou mal implémenté. On peut se connecter sans être le bon utilisateur, ou deviner un mot de passe trop facilement, ou voler une session.
Un scénario. Un site n'a pas de rate limiting sur le formulaire de connexion. Un attaquant lance credential stuffing : il teste 10 millions de combinaisons email/mot de passe volées sur un autre site. Si 0,1 % des utilisateurs de ce site utilisent aussi ce mot de passe, il récupère 10 000 comptes en quelques heures. Autres scénarios : absence de MFA (Multi-Factor Authentication), token de session prédictible, reset de mot de passe via un lien qui n'expire jamais, JWT signé avec HS256 et un secret faible crackable en 10 minutes.
La défense. MFA obligatoire sur les comptes sensibles, idéalement avec FIDO2/passkeys plutôt que SMS. Rate limiting sur les endpoints d'authentification (5 tentatives/minute max). Politique de mots de passe NIST SP 800-63B (longueur minimum 12, pas de complexité imposée, vérification contre les leaks). Tokens de session cryptographiquement aléatoires.
5.2 A08 Software and Data Integrity Failures — « Je fais confiance à ce que je ne devrais pas »
L'idée simple. L'application fait confiance à des données ou des composants sans vérifier leur intégrité. L'attaquant intercepte ou substitue ces données pour modifier le comportement.
Un scénario. Un site fetche une bibliothèque JavaScript depuis un CDN sans vérifier son empreinte cryptographique (Subresource Integrity, SRI). Le CDN est compromis, la bibliothèque est remplacée par une version trojanée qui vole les mots de passe des utilisateurs. Autre scénario : une application accepte un objet sérialisé venant de l'utilisateur (désérialisation non sécurisée Java, pickle Python, PHP unserialize) qui contient une chaîne gadget capable d'exécuter du code arbitraire sur le serveur.
La défense. SRI pour toutes les ressources chargées depuis des CDN. Signature cryptographique des mises à jour et des builds (Sigstore, minisign). Jamais de désérialisation d'objet provenant d'une source non contrôlée ; préférer des formats de données comme JSON qui ne peuvent pas contenir de code.
5.3 A09 Security Logging and Monitoring Failures — « L'alarme ne sonne pas »
L'idée simple. L'application ne journalise pas les événements critiques, ne surveille pas les anomalies, ou ne déclenche pas d'alerte quand quelque chose cloche. Conséquence : une attaque peut durer des semaines avant d'être détectée.
Un scénario. Un attaquant compromet un compte utilisateur, extrait toutes les données pendant 3 mois, puis chiffre la base en ransomware. Post-mortem : aucun log des connexions administrateur, aucun log des exports massifs, aucune alerte sur les patterns anormaux. Le chiffre moyen 2023-2024 selon le rapport IBM Cost of a Data Breach : 204 jours pour détecter une breach, 73 jours supplémentaires pour la contenir.
La défense. Logger tous les événements de sécurité (login success/failure, changement de privilège, action admin, export de données). Centraliser les logs dans un SIEM (Security Information and Event Management) avec rétention minimum 12 mois. Définir des règles d'alerte sur les patterns suspects (MITRE ATT&CK), vérifier que les alertes parviennent à des humains qui peuvent agir.
6. La dernière : SSRF (A10)
6.1 A10 Server-Side Request Forgery — « Je fais travailler le serveur pour moi »
L'idée simple. L'application permet à un utilisateur de fournir une URL que le serveur va fetcher (pour générer une prévisualisation de lien, importer un fichier, envoyer un webhook). L'attaquant fournit une URL pointant vers une ressource interne que lui-même ne peut pas joindre depuis l'extérieur, et le serveur la fetche à sa place.
Un scénario. Une application offre une feature « Importer une image depuis URL ». L'utilisateur fournit http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role — une adresse spéciale AWS qui, depuis une instance EC2, renvoie les credentials IAM temporaires de l'instance. Le serveur fetche l'URL, retourne les credentials dans la réponse (ou dans un message d'erreur verbeux), et l'attaquant peut maintenant agir en tant que serveur. Avec ces credentials, il peut souvent accéder à d'autres services cloud.
La défense. Allowlist stricte des URLs autorisées (domaines connus, pas d'IP privée, pas de localhost). Interdire les IPs de la plage 169.254.0.0/16 (link-local, métadonnées cloud), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918 privées). Sur AWS, forcer IMDSv2 (Instance Metadata Service v2) qui exige un token de session et bloque les SSRF classiques. Utiliser un proxy dédié pour les requêtes sortantes utilisateur.
7. Comment utiliser le OWASP Top 10 en équipe
Le Top 10 n'est pas une checklist à cocher, c'est une grille de lecture et un langage commun.
7.1 Pour un développeur
- Pendant le dev : avant chaque feature touchant à l'authentification, aux données sensibles, aux inputs utilisateur, se poser la question « quelle(s) catégorie(s) OWASP pourraient s'appliquer ici ? »
- En revue de code : les commentaires de code review peuvent référencer les catégories : « A01 — vérification d'autorisation manquante ligne 87 », « A03 — concaténation SQL directe à revoir avec prepared statement ».
- Ressources à connaître : OWASP Cheat Sheet Series (100+ fiches pratiques par sujet), OWASP Proactive Controls v3.
7.2 Pour un chef de projet / product manager
- Dans les user stories : ajouter systématiquement un critère « Non-functional : aucune vulnérabilité OWASP Top 10 majeure introduite » avec test associé.
- Arbitrage priorités : un finding A01 ou A03 se traite en sprint courant, pas au trimestre prochain.
7.3 Pour un RSSI ou responsable sécurité PME
- Cadrer un pentest : exiger une couverture explicite des 10 catégories dans la proposition, pas un scan générique.
- Dashboard exécutif : reporter mensuellement le nombre de findings OWASP par catégorie pour visualiser les tendances.
- Formation : plan annuel avec au moins une formation OWASP Top 10 par développeur (plateforme SecureFlag, HackEDU, ou bootcamp interne).
7.4 Pour un apprenant en reconversion
Ordre d'apprentissage pratique recommandé (en labs) :
- A03 Injection : SQL injection sur DVWA, XSS sur HackTheBox Starting Point.
- A01 Broken Access Control : IDOR et privilege escalation sur PortSwigger Web Security Academy.
- A07 Authentication : bypass, JWT, session management.
- A02 Cryptographic Failures : hashes faibles, TLS mal configuré.
- A10 SSRF : PortSwigger SSRF labs.
- A06 Vulnerable Components : exploitation Log4Shell dans un lab dédié.
Pour approfondir, voir la roadmap AppSec qui structure le parcours complet sur 9-12 mois, la roadmap API security pour le pendant API, et la roadmap secure coding pour l'angle développeur.
Points clés à retenir
- OWASP Top 10 Web 2021 = version stable en 2026, 2025 RC1 en draft. 10 catégories A01 à A10.
- Trois catégories prioritaires à connaître avant tout : A01 Broken Access Control (la plus fréquente), A03 Injection (la plus célèbre), A07 Authentication (la porte d'entrée).
- Chaque catégorie = une idée simple + un scénario concret + une défense principale. Pas besoin de mémoriser, besoin de comprendre.
- Top 10 = langage commun entre dev, PM, RSSI, pentesters, auditeurs. Utilisé dans les rapports, les cahiers des charges, les formations.
- Ne pas confondre Top 10 Web, Top 10 API Security, Top 10 Mobile, Top 10 LLM Applications — référentiels distincts maintenus par OWASP.
- Apprentissage pratique via PortSwigger Web Security Academy (gratuit), HackTheBox, TryHackMe, DVWA — pas uniquement en lecture théorique.
- En équipe : Top 10 référencé dans les revues de code, les user stories, les cahiers des charges pentest, les dashboards RSSI.
