Chapitre 16.1 — OWASP Top 10 & ASVS
⏱️ TL;DR — Récapitulatif de la grille de lecture globale. Le OWASP Top 10 classe les familles de risques web les plus critiques ; ce cours en a couvert chacune. Ce chapitre les remet en un tableau, avec pour chaque famille : le mécanisme (comment ça marche), la parade (comment on ferme), et le renvoi au(x) chapitre(s) détaillé(s). On rappelle aussi l’ASVS (référentiel de vérifications, pour aller plus loin) et l’API Security Top 10 (spécifique aux API, avec le BOLA/IDOR en tête). À utiliser comme carte : quand un risque te vient à l’esprit, tu retrouves ici le principe et où l’approfondir.
🎯 Objectifs
- Avoir une vue d’ensemble des familles de risques et de leurs parades.
- Relier chaque risque OWASP au chapitre correspondant du cours.
- Savoir utiliser Top 10, ASVS et API Top 10 comme références.
Le Top 10 OWASP, mappé sur le cours
Rappel (Partie 1.4) : le Top 10 liste des catégories de risques, pas des failles précises. Voici la synthèse mécanisme → parade → où approfondir :
| Famille de risque | Mécanisme (en bref) | Parade principale | Dans le cours |
|---|---|---|---|
| Broken Access Control | Accéder à ce qu’on ne devrait pas (IDOR, function-level, mass assignment) | Vérifier l’accès côté serveur, par objet, à chaque requête | Partie 5 |
| Cryptographic Failures | Crypto mal utilisée, données sensibles exposées | Hacher les mots de passe (argon2), chiffrer avec clé gérée, ne pas rouler sa crypto | P3, P13 |
| Injection (SQLi, command, XSS…) | Entrée traitée comme du code | Séparer code et données : paramétrer, encoder | P6, P7 |
| Insecure Design | Défaut de conception (pas un bug) | Threat modeling, principes (moindre privilège, fail secure) | P1 |
| Security Misconfiguration | Config par défaut, en-têtes manquants, erreurs verbeuses | En-têtes de sécurité, durcissement, masquer les erreurs | P2, P14 |
| Vulnerable & Outdated Components | Dépendance vulnérable/obsolète | audit, Dependabot, verrouiller, mettre à jour | P12 |
| Identification & Auth Failures | Auth faible (mots de passe, sessions, bruteforce) | Hachage fort, MFA, sessions solides, rate limiting | P4 |
| Software & Data Integrity Failures | Supply chain, désérialisation, MAJ non vérifiées | Provenance, SRI, ne pas désérialiser d’entrée | P9, P12 |
| Security Logging & Monitoring Failures | Attaque non détectée (pas de logs/alertes) | Journaliser (sans fuite), détecter, alerter | P15 |
| Server-Side Request Forgery (SSRF) | Forcer le serveur à requêter une URL interne | Allow-list de destinations, bloquer les IP internes | P8 |
Cette table est la structure du cours : chaque famille a sa partie. Si tu ne devais retenir qu’une ligne, ce serait la première — Broken Access Control, le risque n°1, et le plus facile à oublier.
Les autres grands risques traités
Au-delà des dix catégories, le cours a couvert des risques transversaux ou spécifiques, tout aussi importants :
| Risque | Parade | Dans le cours |
|---|---|---|
| CSRF | Jeton anti-CSRF + SameSite + Origin | Partie 8.1 |
| Clickjacking | frame-ancestors / X-Frame-Options | P8.3 |
| Open redirect | Rediriger vers des chemins internes / allow-list | P8.3 |
| CORS mal configuré | Allow-list d’origines, jamais * + credentials | P8.4 |
| Secrets commités | Hors du code (vault/env), révoquer si fuité | P13 |
| Fuite de PII (logs, réponses) | Minimisation, DTO, rédaction des logs | P13.3 |
| Upload / LFI / désérialisation | Type réel, stockage non exécutable, allow-list, JSON | P9.2 |
ASVS : la checklist exhaustive
Là où le Top 10 dit « voici les grands risques », l’ASVS (Application Security Verification Standard) dit « voici précisément ce qu’il faut vérifier » — des centaines d’exigences testables, organisées par niveaux (L1 basique → L3 exigeant) et par domaines (authentification, contrôle d’accès, validation, crypto, logs…). On l’utilise comme :
- Checklist de revue/conformité : passer les exigences pertinentes pour son niveau de risque.
- Cahier des charges de sécurité pour un nouveau projet.
- Référence quand on veut le détail d’une exigence.
Les Cheat Sheets OWASP (par sujet : Auth, XSS Prevention, SQL Injection Prevention, Password Storage…) complètent, orientées implémentation.
API Security Top 10 : pour les API
Si tu construis des API (back Symfony, route handlers Next.js), le OWASP API Security Top 10 est spécifiquement pertinent. Son risque n°1 est le BOLA (Broken Object Level Authorization) — l’IDOR appliqué aux objets d’API (Partie 5). Il insiste aussi sur l’authentification, l’autorisation au niveau des propriétés et des fonctions, la sur-exposition de données (renvoyer trop de champs — Partie 13), et l’absence de rate limiting. Bref, les mêmes principes, focalisés sur les API.
📚 La source — Ces référentiels évoluent (le Top 10 est révisé périodiquement, l’ASVS et les cheat sheets sont mis à jour). Consulte le site OWASP pour la version courante ; ce chapitre te donne la carte (familles + parades + où approfondir), pas une liste figée. Comme dit en Partie 1.4 : mémorise les familles et leurs parades, pas des numéros de version.
🧭 Sur FormaCampus — L’équipe FormaCampus utilise cette grille comme référence partagée : le Top 10 structure ses revues (chaque famille est une question à se poser), l’ASVS sert de checklist pour les fonctionnalités sensibles et les audits, l’API Top 10 guide la sécurité de l’API (BOLA/IDOR en priorité), et les cheat sheets sont ouvertes au moment d’implémenter une parade précise. Cette table (mécanisme → parade → chapitre) est affichée dans leur doc interne comme point d’entrée.
✏️ Exercices
Exercice 1 — Retrouve la parade. Pour chaque risque, donne la parade principale de mémoire : (a) Injection, (b) Broken Access Control, (c) SSRF, (d) Cryptographic Failures (mots de passe).
✅ Solution
(a) Injection → séparer code et données : requêtes préparées/ORM (SQL), arguments en tableau sans shell (command), encodage de sortie (XSS). (b) Broken Access Control → vérifier l’accès côté serveur, par objet, à chaque requête (requête portée par le propriétaire/tenant), deny by default. (c) SSRF → allow-list de destinations + rejeter les IP internes/privées/link-local (métadonnées cloud), segmentation réseau. (d) Cryptographic Failures (mots de passe) → hacher avec un algorithme lent et salé (argon2id/bcrypt), jamais en clair ni chiffré ni SHA nu. Ce sont les parades principales ; le cours détaille les couches autour.
Exercice 2 — Top 10 vs ASVS. Ton équipe veut « vérifier sérieusement » la sécurité d’une fonctionnalité d’authentification avant sa mise en prod. Utilises-tu le Top 10 ou l’ASVS, et pourquoi ?
✅ Solution
Pour une vérification sérieuse et détaillée, on utilise l’ASVS : il fournit une checklist exhaustive d’exigences testables par domaine (ici, le chapitre Authentification de l’ASVS liste précisément ce qu’il faut vérifier : stockage des mots de passe, politique, MFA, gestion de session, protection contre le bruteforce, messages génériques, etc.). Le Top 10 est une grille de lecture de haut niveau (les familles de risques) — utile pour cadrer et sensibiliser, mais trop général pour une vérification fine. La bonne démarche : le Top 10 pour identifier les familles concernées (ici « Identification & Authentication Failures »), puis l’ASVS (au niveau de risque adapté) comme checklist détaillée pour la revue, complété par la cheat sheet Authentication au moment d’implémenter. Top 10 = carte ; ASVS = checklist ; cheat sheet = mode d’emploi.
🧠 Quiz de révision
1. Quel est le risque n°1 du Top 10, et sa parade ?
Broken Access Control : accéder à ce qu’on ne devrait pas (IDOR, function-level, mass assignment). Parade : vérifier l’accès côté serveur, par objet, à chaque requête (requête portée par le propriétaire/tenant, deny by default) — Partie 5. C’est aussi le plus facile à oublier.
2. Quelle est la différence entre le Top 10 et l’ASVS ?
Le Top 10 liste les grandes familles de risques (grille de lecture, haut niveau). L’ASVS est un référentiel détaillé de vérifications testables (checklist exhaustive par domaine et par niveau). Top 10 pour cadrer, ASVS pour vérifier finement.
3. Qu’est-ce que le BOLA, et où le situe-t-on ?
Le BOLA (Broken Object Level Authorization) est l’IDOR appliqué aux objets d’API : accéder à l’objet d’un autre en changeant un id. C’est le risque n°1 de l’OWASP API Security Top 10. Parade : autorisation par objet côté serveur (Partie 5).
4. Le mécanisme commun à toute la famille « Injection » ?
Une entrée non fiable traitée comme du code par un interpréteur (SQL, shell, LDAP, navigateur pour le XSS). Parade universelle : séparer code et données (paramétrer, arguments en tableau, encoder la sortie) — Parties 6 et 7.
5. Faut-il mémoriser les numéros de version du Top 10 ?
Non : les référentiels évoluent. On mémorise les familles de risques et leurs parades (la carte mécanisme → parade → chapitre), et on consulte le site OWASP pour la version courante et le détail.
Chapitre suivant : Checklist revue de code — quoi chercher, systématiquement, dans chaque pull request.