Chapitre 1.4 — OWASP & l’état d’esprit
⏱️ TL;DR — OWASP (Open Worldwide Application Security Project) est la référence communautaire et gratuite de la sécurité applicative. Trois ressources à connaître : le Top 10 (les dix risques web les plus critiques, la porte d’entrée), l’ASVS (un référentiel détaillé de vérifications, pour aller plus loin) et les Cheat Sheets (des fiches pratiques par sujet). Mais l’outil le plus puissant n’est pas une liste : c’est un état d’esprit. Apprends à te demander, devant chaque fonctionnalité, « comment j’attaquerais ça ? » — penser en attaquant est ce qui permet de coder en défenseur.
🎯 Objectifs
- Savoir ce qu’est OWASP et à quoi servent le Top 10, l’ASVS et les Cheat Sheets.
- Utiliser le Top 10 comme grille de lecture d’une appli (sans le réciter par cœur).
- Adopter la bascule mentale attaquant ↔ défenseur face à une fonctionnalité.
- Comprendre pourquoi cette posture est la compétence la plus transférable du cours.
OWASP, la boussole
OWASP est une fondation à but non lucratif qui produit des ressources ouvertes sur la sécurité des logiciels. Ce n’est ni un produit ni une norme obligatoire, mais le point de référence partagé de la profession : quand un dev, un pentesteur ou un RSSI parle du « Top 10 » ou de l’« ASVS », tout le monde sait de quoi il s’agit. Le cours s’y adosse en permanence.
📚 La source — OWASP est la principale source qu’on cite dans ce cours (via l’encadré « La source »). Ses ressources évoluent (le Top 10 est révisé périodiquement, les cheat sheets sont mises à jour) : on enseigne ici les catégories et les mécanismes, et on te renvoie au site OWASP pour la version courante et les détails. Ne mémorise pas des numéros de version ; mémorise les familles de risques et leurs parades.
Le Top 10 : la porte d’entrée
Le OWASP Top 10 classe les dix catégories de risques web les plus critiques, établies à partir de données réelles. Ce n’est pas une liste de failles précises mais de familles. Les grandes catégories, qui structurent d’ailleurs ce cours :
| Catégorie (famille) | Traitée dans ce cours |
|---|---|
| Broken Access Control (contrôle d’accès cassé, IDOR) | Partie 5 |
| Cryptographic Failures (crypto mal utilisée, données exposées) | Partie 3, Partie 13 |
| Injection (SQLi, command, XSS inclus) | Partie 6, Partie 7 |
| Insecure Design (défaut de conception, pas de bug) | Partie 1 (threat modeling) |
| Security Misconfiguration (config par défaut, headers manquants) | Partie 2, Partie 14 |
| Vulnerable & Outdated Components (dépendances) | Partie 12 |
| Identification & Authentication Failures | Partie 4 |
| Software & Data Integrity Failures (supply chain, désérialisation) | Partie 9, Partie 12 |
| Security Logging & Monitoring Failures | Partie 15 |
| Server-Side Request Forgery (SSRF) | Partie 8 |
Il existe aussi un OWASP API Security Top 10, spécifique aux API (très pertinent pour un back Symfony ou des route handlers Next.js), dont le risque n°1 est le BOLA (Broken Object Level Authorization) — l’IDOR appliqué aux objets d’API. On y reviendra en Partie 5.
ASVS et Cheat Sheets : pour agir
- L’ASVS (Application Security Verification Standard) est un référentiel de vérifications organisé par niveaux d’exigence. Là où le Top 10 dit « voici les grands risques », l’ASVS dit « voici précisément ce qu’il faut vérifier » (des centaines d’exigences testables). Utile comme checklist de revue et de conformité (on y revient en Partie 16).
- Les Cheat Sheets sont des fiches pratiques par sujet (Authentication, XSS Prevention, SQL Injection Prevention, CSRF, Password Storage…). Concrètes, orientées code : c’est souvent la première chose à ouvrir quand on implémente une défense précise.
💡 Réflexe — N’essaie pas d’« apprendre OWASP par cœur ». Sers-t’en comme d’une boussole : le Top 10 pour savoir quelles familles de risques existent, l’ASVS pour une checklist exhaustive au moment d’une revue, et la Cheat Sheet du sujet précis quand tu implémentes une parade. C’est un réflexe d’ouverture de fiche, pas un examen de mémoire.
L’état d’esprit : penser en attaquant
Toutes les listes du monde ne remplacent pas la vraie compétence : le regard. Un bon dev défensif a intériorisé une habitude — devant chaque fonctionnalité qu’il écrit, il se demande spontanément « si je voulais casser ça, comment je m’y prendrais ? ».
Cette bascule change tout, parce qu’un attaquant ne voit pas ton appli comme toi. Toi, tu vois un parcours prévu (« l’utilisateur remplit le formulaire, clique, ça marche »). L’attaquant voit une machine à manipuler :
- « Et si j’envoie ce champ vide ? Énorme ? Avec des caractères spéciaux ? »
- « Et si je change cet id dans l’URL pour celui d’un autre ? »
- « Et si j’appelle cet endpoint sans passer par le formulaire, avec
curl? » - « Et si je saute une étape du parcours et j’appelle directement la dernière ? »
- « Et si je rejoue deux fois cette requête ? »
- « Ce message d’erreur, qu’est-ce qu’il me révèle ? »
Chacune de ces questions, posée pendant que tu codes, mène à une parade. C’est exactement le mouvement du cours : on te montre l’attaque (le regard offensif) pour que la défense devienne évidente.
🎯 Côté attaquant — L’attaquant travaille sur les hypothèses implicites du développeur. Chaque fois que tu penses « ça n’arrivera jamais » (« personne n’enverra un id négatif », « le front empêche déjà ça », « qui irait mettre un
<script>dans son nom ? »), tu poses une hypothèse qu’un attaquant va précisément tester. La sécurité, c’est rendre tes hypothèses explicites et les vérifier, plutôt que d’y faire confiance.
Attaquer pour défendre… dans un cadre
Penser en attaquant est un exercice mental et une pratique autorisée (tester ta propre appli, un environnement dédié, un CTF, un programme de bug bounty qui t’y invite). Ça ne signifie évidemment pas attaquer des systèmes qui ne t’appartiennent pas : tester une appli sans autorisation est illégal. Dans tout le cours, l’offensive sert un seul but — comprendre pour mieux fermer, sur tes propres systèmes.
🧭 Sur FormaCampus — L’équipe FormaCampus a instauré un rituel léger : à chaque revue de PR, le relecteur enfile le « chapeau d’attaquant » cinq minutes et note tout ce qu’il tenterait pour casser la fonctionnalité (id d’un autre, champ manquant, appel direct de l’endpoint, entrée piégée). Ces notes deviennent des cas de test et des correctifs. Résultat : les failles sont trouvées par l’équipe, en revue, pas par un bot en prod. C’est OWASP + l’état d’esprit, appliqués au quotidien.
✏️ Exercices
Exercice 1 — Range dans le Top 10. Associe chaque faille à sa famille OWASP : (a) un endpoint /api/users/:id renvoie n’importe quel utilisateur sans vérifier qui demande ; (b) les mots de passe sont stockés en SHA-1 sans sel ; (c) une dépendance npm connue vulnérable n’est pas mise à jour ; (d) le serveur renvoie des stacktraces complètes en prod.
✅ Solution
(a) Broken Access Control (l’objet demandé n’est pas autorisé pour le demandeur → IDOR/BOLA). (b) Cryptographic Failures (stockage de mot de passe inadéquat : SHA-1 sans sel, non conçu pour ça). (c) Vulnerable & Outdated Components. (d) Security Misconfiguration (fuite d’informations via des erreurs verbeuses en production).
Exercice 2 — Le chapeau d’attaquant. Tu écris une fonctionnalité « réinitialiser mon mot de passe » (l’utilisateur saisit son email, reçoit un lien). Pose quatre questions d’attaquant sur cette fonctionnalité.
✅ Solution
Par exemple : (1) « La réponse me dit-elle si l’email existe ? » (fuite d’énumération de comptes → réponse générique « si un compte existe, un mail est envoyé »). (2) « Le lien/token est-il devinable, réutilisable, sans expiration ? » (→ token aléatoire CSPRNG, à usage unique, à durée courte). (3) « Puis-je spammer l’envoi (déni de service / harcèlement) ? » (→ rate limiting). (4) « Le lien de reset me connecte-t-il directement ou permet-il de fixer une session ? Peut-il fuiter via le Referer ? » (→ pas de token en URL réutilisable, invalider l’ancienne session). Chaque question mène à une parade — c’est le mouvement défensif.
🧠 Quiz de révision
1. Qu’est-ce qu’OWASP, en une phrase ?
Une fondation à but non lucratif qui produit des ressources ouvertes et gratuites sur la sécurité applicative (Top 10, ASVS, Cheat Sheets), servant de référence commune à toute la profession.
2. Quelle est la différence entre le Top 10 et l’ASVS ?
Le Top 10 liste les grandes familles de risques critiques (une grille de lecture, une porte d’entrée). L’ASVS est un référentiel détaillé de vérifications testables, organisé par niveaux — une checklist exhaustive pour la revue et la conformité.
3. Le Top 10 est-il une liste de failles précises ?
Non : c’est une liste de catégories/familles de risques (Broken Access Control, Injection, Cryptographic Failures…). Une même catégorie couvre de nombreuses failles concrètes. On mémorise les familles et leurs parades, pas des numéros de version.
4. Quelle est la question centrale de l’état d’esprit défensif ?
« Si je voulais casser ça, comment je m’y prendrais ? » — posée pendant qu’on code chaque fonctionnalité. Elle rend explicites les hypothèses implicites (« ça n’arrivera jamais ») et mène directement aux parades.
5. Sur quelles hypothèses l’attaquant travaille-t-il ?
Sur les hypothèses implicites du développeur : « personne n’enverra un id négatif », « le front empêche déjà ça », « qui mettrait un <script> dans son nom ». Chaque « ça n’arrivera jamais » est précisément ce que l’attaquant teste. Sécuriser = rendre ces hypothèses explicites et les vérifier.
Fin de la Partie 1. Tu as maintenant la boussole : CIA, surface, defense in depth, STRIDE, OWASP, et l’état d’esprit attaquant/défenseur. Direction la Partie 2 — HTTP, navigateur & confiance pour poser les fondations techniques sur lesquelles reposent toutes les attaques web.