Sécurité web & applicative — penser en attaquant, coder en défenseur

⏱️ TL;DR — Ton appli tourne, elle est en ligne… et elle est attaquée en permanence. Ce cours te fait passer de « je code des fonctionnalités » à « je code des fonctionnalités qui tiennent ». Tu vas comprendre comment marchent les grandes attaques (XSS, injections, CSRF/SSRF, broken access control, auth cassée, secrets qui fuient, dépendances vérolées), puis écrire le code qui les neutralise dans ton stack : JavaScript, PHP/Symfony, Next.js/React, Moodle et sur le serveur Linux. Pas une liste de peurs : des mécanismes clairs et des correctifs prêts à copier. De l’état d’esprit attaquant à la prod durcie — la compétence qui fait de toi un dev en qui on a confiance.

À qui s’adresse ce cours

À toi : un développeur web (JavaScript / TypeScript, Next.js / React, mais aussi PHP / Symfony, Node, Moodle, et un VPS Linux) qui sait coder et livrer, mais pour qui « sécuriser » est resté flou, tardif, ou le job « de quelqu’un d’autre ». Tu connais OWASP de nom, tu as déjà entendu « échappe tes entrées » — mais tu n’as jamais construit un modèle de menace, tu ne sais pas vraiment pourquoi une requête préparée protège, ni où ton appli fuit. Aucune expertise sécu préalable n’est requise, juste de savoir lire du code. À la fin, tu sauras repérer une faille dans une revue de code, expliquer comment elle s’exploite, et la fermer — sur tout ton stack.

💡 Le pari central de ce cours — La sécurité a la réputation d’être « un truc de spécialistes », ennuyeux, qu’on ajoute à la fin. Faux, faux, et dangereux. C’est une compétence de dev qui se pratique à chaque ligne, et elle est apprenable : chaque attaque a un mécanisme précis, et chaque mécanisme a une parade précise. Un dev qui conçoit sécurisé ne livre pas une fuite de données ou un ransomware qui attend son heure — il livre du logiciel fiable. Peu de devs full-stack maîtrisent vraiment la sécurité de bout en bout. Ceux qui le font sont ceux à qui on confie les projets sensibles. C’est exactement ce qui te rend rare.

Ce que tu sauras faire à la fin

• Modéliser la menace d’une appli (STRIDE, surface d’attaque, frontières de confiance) et raisonner en defense in depth.
• Maîtriser les fondations : origines, cookies (HttpOnly/Secure/SameSite), en-têtes de sécurité (CSP, HSTS), ce que HTTPS protège… et ne protège pas.
• Utiliser la crypto correctement : hacher des mots de passe en argon2id, générer de l’aléatoire sûr, comprendre les JWT et leurs pièges — sans jamais rouler ta propre crypto.
• Construire une authentification solide (sessions vs tokens, MFA, passkeys, OAuth2/OIDC) et une autorisation sans IDOR (vérifier l’accès côté serveur, à chaque requête).
• Fermer les injections (SQLi → requêtes préparées PDO/Doctrine/$DB), le XSS (encodage, DOMPurify, CSP, auto-échappement React/Twig), le CSRF, le SSRF et configurer CORS correctement.
• Sécuriser ton stack en pratique : PHP/Symfony (firewalls, voters, secrets), Next.js/React/Node (frontière client/serveur, Server Actions, npm audit), Moodle (capabilities, sesskey, $DB).
• Gérer les secrets et les données sensibles, verrouiller la supply chain (audit, Dependabot, SRI), durcir l’infra (en-têtes, rate limiting, CI/CD).
• Détecter, journaliser et répondre à un incident — jusqu’à la notification de violation (lien RGPD).

Le sommaire

Le fil rouge : FormaCampus

Tout au long du cours, on sécurise FormaCampus — la même EdTech française (SaaS Next.js + API Symfony + PostgreSQL, avec un Moodle) que dans les cours Moodle, RGPD, Interop EdTech et Serveur Linux, vue cette fois sous l’angle sécurité. Elle manipule des données sensibles d’apprenants : une fuite serait un désastre RGPD et de réputation. On va modéliser sa menace, durcir son auth et son autorisation (pas d’IDOR entre formateurs), fermer les injections et le XSS (Doctrine, Twig, DOMPurify, CSP), gérer ses secrets et ses dépendances, durcir son infra, puis apprendre à détecter et répondre à un incident. Chaque partie ferme une classe de risque réelle, dans l’encadré 🧭 Sur FormaCampus.

Comment lire ce cours

• Dans l’ordre la première fois : on part de l’état d’esprit et des fondations (parties 1-3), on monte sur les grands mécanismes (auth, autorisation, injections, XSS, CSRF/SSRF — parties 4-8), puis on applique à ton stack (PHP/Symfony, Next.js, Moodle — parties 9-11), et on industrialise (supply chain, secrets, infra, incident — parties 12-16).
• En référence ensuite : le Cookbook & Annexes rassemble le récap OWASP Top 10, les checklists (revue de code sécu, mise en prod), les cheatsheets par techno et un glossaire.
• On lit du code : chaque faille est montrée en vulnérable puis corrigé. Rejoue-les mentalement — c’est en voyant pourquoi le mauvais code casse que la parade devient évidente.

🛡️ La règle d’or de tout le cours — Ne fais jamais confiance à une entrée. Tout ce qui vient de l’extérieur de ton serveur — corps de requête, URL, en-têtes, cookies, formulaires, fichiers uploadés, réponses d’API tierces, et même le contenu de ta propre base si un tiers a pu l’écrire — est hostile jusqu’à preuve du contraire. Valide en entrée, encode en sortie, vérifie l’accès côté serveur. Cette phrase résume 80 % de la sécurité applicative.

⚠️ Piège — Le plus grand piège du dev, c’est de croire que « personne ne va s’attaquer à mon petit projet ». Faux : l’immense majorité des attaques sont automatisées et indiscriminées — des bots scannent Internet en continu à la recherche de la moindre appli vulnérable, sans savoir ni se soucier de ce qu’elle fait. Tu n’as pas besoin d’être une cible pour être une victime. On code sécurisé par défaut, pas « quand le projet sera assez gros ».

Prêt ? On commence par le plus important : comprendre la sécurité et adopter l’état d’esprit qui change tout.