Chapitre 16.4 — DevSecOps, glossaire & quiz final
⏱️ TL;DR — Le mot de la fin. DevSecOps, c’est intégrer la sécurité dans le flux de développement (shift-left, Partie 1) plutôt que comme une étape séparée : automatisée en CI, présente à chaque PR, portée par toute l’équipe — pas déléguée à une « équipe sécu » mythique. Se tenir à jour est une compétence : la sécurité évolue (nouvelles attaques, nouveaux correctifs), donc on suit OWASP, les avis de sécurité, quelques sources fiables. On clôt par un glossaire des termes du cours et un quiz final transversal pour ancrer l’essentiel. La sécurité n’est pas un état qu’on atteint, c’est une pratique qu’on entretient.
🎯 Objectifs
- Comprendre la culture DevSecOps (sécurité intégrée, pas séparée).
- Savoir se tenir à jour en sécurité (sources, veille).
- Disposer d’un glossaire des termes du cours.
- Valider l’essentiel avec un quiz final transversal.
DevSecOps : la sécurité dans le flux
Tout le cours a défendu une idée : la sécurité n’est pas une phase finale ni le job d’« autres », c’est un attribut de qualité présent à chaque étape (Partie 1). DevSecOps est le nom de cette pratique — intégrer la sécurité dans le cycle de dev :
- Automatiser en CI/CD : audit des dépendances, scan de secrets, SAST, scan d’images, vérification des en-têtes — bloquants (Parties 12, 14, 16.2-16.3). Ce que la machine peut vérifier, elle le vérifie à chaque fois, sans dépendre de la vigilance.
- Sécurité à chaque PR : checklist de revue (16.2), réflexe « chapeau d’attaquant » (1.4), autorisation par objet vérifiée par l’humain.
- Sécurité partagée : toute l’équipe est responsable, pas un silo « sécu » consulté à la fin. Le dev qui écrit la fonctionnalité est le mieux placé pour la sécuriser (1.1).
- Shift-left : sécuriser tôt (conception, code) où c’est le moins cher et le plus efficace (1.1).
- Apprendre des incidents : post-mortems sans blâme (15.3) qui produisent des correctifs durables.
DevSecOps n’est pas un outil qu’on achète, c’est une façon de travailler : la sécurité devient un réflexe collectif, automatisé là où c’est possible, humain là où c’est nécessaire.
Se tenir à jour : une compétence
La sécurité bouge : de nouvelles classes d’attaques apparaissent, des CVE tombent quotidiennement, les bonnes pratiques évoluent (le stockage des mots de passe, les recommandations TLS, les mécanismes d’auth). Ce que tu as appris est la fondation ; la maintenir à jour est une compétence continue :
- Suivre OWASP : Top 10, ASVS, Cheat Sheets (mis à jour) — la référence (1.4, 16.1).
- Suivre les avis de sécurité de tes dépendances et outils (Dependabot, advisories, listes de diffusion — Parties 11-12).
- Quelques sources fiables : blogs de sécurité reconnus, publications de chercheurs, comptes-rendus d’incidents (on apprend beaucoup des post-mortems publics).
- Pratiquer : CTF, labs, bug bounty (sur des cibles autorisées), relire son propre code avec le chapeau d’attaquant.
- Rester humble : personne ne sait tout, la sécurité est un domaine vaste et mouvant. Savoir où chercher (la bonne cheat sheet, la bonne doc) vaut mieux que prétendre tout retenir.
💡 Réflexe — La sécurité n’est pas un diplôme qu’on obtient une fois, c’est une pratique qu’on entretient. Garde deux habitudes : (1) automatiser ce qui peut l’être (pour ne pas dépendre de ta mémoire), (2) rester curieux (lire un post-mortem, suivre OWASP, tester une attaque sur ton propre code). Le dev qui progresse en sécurité n’est pas celui qui « sait tout », c’est celui qui a intégré les réflexes et sait où approfondir. C’est exactement ce que ce cours a visé.
Glossaire
| Terme | Définition courte |
|---|---|
| CIA | Confidentialité, Intégrité, Disponibilité — les 3 propriétés protégées (P1). |
| Defense in depth | Empiler plusieurs couches de défense indépendantes (P1). |
| Moindre privilège | Ne donner que les droits strictement nécessaires (P1). |
| Fail secure | En cas d’erreur, échouer fermé (refuser), pas ouvert (P1). |
| Threat modeling / STRIDE | Modéliser les menaces d’un système ; STRIDE = 6 catégories (P1). |
| OWASP / Top 10 / ASVS | Référence sécurité ; familles de risques ; référentiel de vérifications (P1, P16). |
| Same-Origin Policy (SOP) | Isolation navigateur : une origine ne lit pas les données d’une autre (P2). |
| CORS | Assouplissement contrôlé de la SOP (autoriser la lecture cross-origin) (P8). |
| CSP | Content-Security-Policy : filet anti-XSS (sources de scripts autorisées) (P2, P7). |
| HSTS | Force le HTTPS pour les visites suivantes (P2, P14). |
| Hacher / chiffrer / encoder | À sens unique / réversible avec clé / réversible non secret (P3). |
| argon2id / bcrypt | Hachages lents et salés pour les mots de passe (P3, P4). |
| CSPRNG | Générateur d’aléatoire cryptographique (pas Math.random()) (P3). |
| JWT | Jeton signé (payload lisible, pas chiffré) ; pièges alg:none, expiration (P3). |
| MFA / TOTP / passkey (WebAuthn) | Second facteur ; codes temporaires ; auth cryptographique anti-phishing (P4). |
| Session vs token | État côté serveur (révocable) vs auto-porté côté client (P4). |
| RBAC / ABAC | Droits par rôle / par attributs (appartenance, contexte) (P5). |
| IDOR / BOLA | Accéder à l’objet d’un autre en changeant un id (Broken Access Control) (P5). |
| Injection | Entrée traitée comme du code ; parade = paramétrer (P6). |
| Requête préparée | Séparer code SQL et données (placeholders + paramètres) (P6). |
| XSS (stored/reflected/DOM) | Injection de JS dans le navigateur d’autrui ; parade = encoder/sanitizer/CSP (P7). |
| Sanitization / DOMPurify | Nettoyer du HTML riche (allow-list de balises sûres) (P7). |
| CSRF | Requête forcée au nom d’une victime ; parade = jeton + SameSite + Origin (P8). |
| SSRF | Forcer le serveur à requêter une URL interne (métadonnées cloud) (P8). |
| Clickjacking | Iframe invisible détournant les clics ; parade = frame-ancestors (P8). |
| Voter / capability / policy | Contrôle d’accès centralisé (Symfony / Moodle / générique) (P9-P11). |
| sesskey | Jeton anti-CSRF de Moodle ; $DB = API paramétrée (P11). |
| CVE | Identifiant public d’une vulnérabilité connue (P12). |
| Supply chain / typosquatting | Risque des dépendances ; paquet malveillant au nom proche (P12). |
Lockfile / npm ci | Verrouiller et installer les dépendances exactes (intégrité) (P12). |
| SRI / SBOM / provenance | Intégrité des ressources / inventaire des composants / origine (P12). |
| PII | Données à caractère personnel (enjeu sécurité + RGPD) (P13). |
| Vault / rotation | Stockage sécurisé des secrets / les changer régulièrement (P13). |
| Rate limiting / WAF / fail2ban | Limiter l’abus / filtrer / bannir les IP hostiles (P14). |
| OIDC (CI) | Identité fédérée → credentials temporaires (vs clés long-lived) (P14). |
| Réponse à incident | Préparer → contenir → éradiquer → rétablir → apprendre (P15). |
| Violation de données | Fuite de PII → obligations RGPD (notification 72 h) (P15). |
| DevSecOps / shift-left | Sécurité intégrée au flux, tôt et automatisée (P1, P16). |
Le mot de la fin
Tu as parcouru la sécurité applicative de l’état d’esprit (penser en attaquant) aux mécanismes (chaque attaque, sa parade), à ton stack (PHP/Symfony, Next.js, Moodle, Linux), jusqu’à l’industrialisation (supply chain, secrets, infra, détection, réponse). Le fil rouge — ne jamais faire confiance à une entrée, vérifier côté serveur, defense in depth — traverse tout. Tu ne connais pas toutes les failles (personne ne les connaît), mais tu as les réflexes pour les reconnaître et les fermer, et tu sais où approfondir. C’est ce qui fait un dev en qui on a confiance pour livrer du logiciel qui tient. Bonne route — et garde le chapeau d’attaquant à portée de main.
🧠 Quiz final (transversal)
1. En une phrase, quelle est la règle d’or de tout le cours ?
Ne jamais faire confiance à une entrée : tout ce qui vient de l’extérieur du serveur est hostile jusqu’à preuve du contraire → valider en entrée, encoder en sortie, vérifier l’accès côté serveur. C’est ~80 % de la sécurité applicative.
2. Un utilisateur connecté accède à /api/factures/124 (pas la sienne) et la reçoit. Quel risque, quelle parade ?
/api/factures/124 (pas la sienne) et la reçoit. Quel risque, quelle parade ?IDOR / Broken Access Control (risque n°1). Parade : vérifier l’autorisation par objet côté serveur — requête portée par le propriétaire (WHERE id = :id AND owner_id = :moi), via un voter/policy centralisé, refuser (404/403) sinon. Authentifié ≠ autorisé (P5).
3. Où stockes-tu un mot de passe, un token d’API, et un identifiant de session ?
Mot de passe : haché (argon2id), jamais réversible (P3). Token d’API (secret) : dans un vault/variables d’environnement, jamais dans Git ni exposé au client (P13). Identifiant de session : opaque, dans un cookie HttpOnly/Secure/SameSite (pas localStorage), état côté serveur (P4).
4. Ton front (app.site.fr) appelle ton API (api.site.fr). Que faut-il, et quel piège éviter ?
Origines différentes → CORS avec une allow-list d’origines exactes et Allow-Credentials: true. Pièges : jamais * + credentials, jamais de miroir non validé de l’Origin. Et CORS ne protège pas l’API (elle reste défendue par auth/autorisation/CSRF) (P8).
5. Une Server Action supprimer(id) : quels contrôles, et pourquoi ?
supprimer(id) : quels contrôles, et pourquoi ?Auth (session), validation (schéma Zod), autorisation par objet (l’objet appartient-il au demandeur ?). Parce qu’une Server Action est un endpoint exposé appelable directement avec n’importe quels arguments — pas un appel local de confiance. Le typage TS ne valide pas au runtime (P10).
6. HTTPS suffit-il à sécuriser une appli ? Justifie.
Non : HTTPS protège le transport (nécessaire, le « sol »), mais pas les failles applicatives (XSS, injection, IDOR, auth faible) qui vivent aux extrémités. « Nécessaire mais pas suffisant ». Le cadenas ne dit pas « site sûr », il dit « connexion chiffrée vers ce domaine » (P2).
7. Une CVE critique tombe sur une de tes dépendances. Que fais-tu ?
La traiter vite (elle est publique → exploitée en masse) : mettre à jour la dépendance en priorité (audit/Dependabot), tester, déployer. Ne pas repousser — la fenêtre entre correctif et exploitation est courte. Un SBOM aide à savoir où on est concerné (P12).
8. Ton appli est compromise via une faille. Cite deux mesures qui auraient borné l’impact.
Moindre privilège (appli sous compte non-root, base non exposée, réseau segmenté ne joignant pas les métadonnées cloud) et isolation (conteneurs non-root, filesystem restreint). Elles ne préviennent pas la faille mais confinent les dégâts. Plus : moindre privilège de l’utilisateur DB (P6, P14).
9. Une fuite de données personnelles est confirmée. Quelles obligations, au-delà du technique ?
C’est une violation de données (RGPD) : documenter, notifier la CNIL sous 72 h si risque pour les personnes, informer les personnes si risque élevé, impliquer le DPO. La sécurité et la conformité sont le même sujet dès qu’il y a des PII (P13, P15, cours RGPD).
10. Quelle est la meilleure attitude pour progresser durablement en sécurité ?
Traiter la sécurité comme une pratique (pas un état atteint) : automatiser ce qui peut l’être (CI), garder le réflexe attaquant à chaque PR, apprendre des incidents (post-mortems), se tenir à jour (OWASP, avis de sécurité), et savoir où approfondir plutôt que prétendre tout retenir. DevSecOps + curiosité (P1, P16).
Fin du cours. Merci d’avoir suivi ce parcours de sécurité web & applicative. Reviens au Cookbook et aux checklists quand tu en as besoin, garde OWASP en marque-page, et applique la règle d’or à chaque ligne : ne fais jamais confiance à une entrée. Pour aller plus loin sur des sujets connexes : RGPD (protection des données), Serveur Linux (déploiement & durcissement), Symfony, Moodle.
Bon code, et code sûr.