Chapitre 1.1 — Pourquoi la sécu est ton problème
⏱️ TL;DR — La sécurité n’est pas le job d’un ops, d’un pentester de dernière minute ou d’une équipe « sécu » mythique : c’est ton job, à toi qui écris le code. Les attaques sont massivement automatisées et indiscriminées — des bots scannent Internet en continu, ils ne te choisissent pas, ils te trouvent. Une faille coûte d’autant plus cher qu’elle est découverte tard (le principe du shift-left). La bonne nouvelle : chaque attaque a un mécanisme précis et une parade précise — c’est apprenable, et ça se joue à chaque ligne.
🎯 Objectifs
- Comprendre pourquoi « mon projet est trop petit pour intéresser un pirate » est un raisonnement faux et dangereux.
- Saisir le coût croissant d’une faille selon le moment où on la trouve (design → code → prod → incident).
- Adopter le principe shift-left : sécuriser tôt, dans le code, pas à la fin.
- Situer ta responsabilité de développeur dans la chaîne de sécurité.
« Personne ne s’attaquera à mon appli »
C’est l’illusion la plus répandue, et la plus coûteuse. Elle repose sur une image fausse de l’attaquant : un humain qui te viserait toi, personnellement, en choisissant ta cible. La réalité est tout autre.
L’écrasante majorité des attaques web sont automatisées. Des réseaux de bots parcourent Internet en permanence, testant des millions d’adresses IP et de domaines à la recherche de n’importe quelle appli présentant une faiblesse connue : un formulaire injectable, une version de dépendance vulnérable, un panneau d’admin exposé, un endpoint sans contrôle d’accès. Le bot ne sait pas ce que fait ton appli, et il s’en moque. Il cherche une porte ouverte, pas une cible de valeur.
🎯 Côté attaquant — Un scanner automatisé ne se demande pas « ce site vaut-il la peine ? ». Il envoie des milliers de requêtes-sondes (
/wp-login.php,/.env,/.git/config,?id=1' OR '1'='1,/admin) à tout ce qui répond, et loggue ce qui mord. Ta petite appli de démo mise en ligne « juste pour tester » reçoit ces sondes dans les minutes qui suivent sa publication. Tu n’as pas besoin d’être visé pour être compromis.
Ce qu’un attaquant tire d’une appli « sans intérêt » :
- Des données : emails, mots de passe (réutilisés ailleurs), données personnelles revendables.
- Une ressource de calcul : miner de la crypto, envoyer du spam, héberger du phishing, servir de relais.
- Un pivot : ta machine compromise devient un tremplin vers d’autres systèmes (le tien, ceux de tes clients).
- Un moyen de pression : chiffrer tes données (ransomware) et demander une rançon.
Autrement dit : toute appli en ligne a de la valeur pour un attaquant, indépendamment de ce qu’elle fait.
Le coût d’une faille grimpe avec le temps
Une même faille ne coûte pas la même chose selon quand on la découvre. C’est le principe le plus important pour justifier de sécuriser tôt.
| Moment de découverte | Ce qu’il faut faire | Coût |
|---|---|---|
| Design | Changer une décision d’architecture (sur le papier). | Quasi nul. |
| Code | Corriger quelques lignes avant merge. | Faible. |
| Revue / tests | Rouvrir une PR, re-tester. | Modéré. |
| Production | Patch d’urgence, redéploiement, communication. | Élevé. |
| Incident | Fuite de données, notification RGPD, perte de confiance, sanctions, temps de remédiation. | Catastrophique. |
Une faille de contrôle d’accès repérée en revue de code, c’est cinq minutes. La même faille exploitée en prod, c’est une fuite de données : notification à la CNIL sous 72 h (voir le cours RGPD), clients à prévenir, réputation entamée, et parfois des sanctions. Le rapport de coût se compte en ordres de grandeur.
💡 Réflexe — C’est ça, le shift-left : déplacer l’effort de sécurité vers la gauche de la timeline, au plus près de la conception et du code. Non pas parce que c’est vertueux, mais parce que c’est radicalement moins cher et plus efficace. Une faille non écrite ne coûte rien à corriger.
Ta place dans la chaîne
« La sécurité, c’est l’équipe sécu / les ops / le pentest final. » Dans la vraie vie d’un projet web, ces maillons existent parfois — mais ils interviennent après toi, et ils ne peuvent pas rattraper une conception non sûre. Le pentesteur trouve des failles ; il ne réécrit pas ton appli. L’ops durcit le serveur ; il ne peut pas deviner que ton endpoint /api/facture/:id ne vérifie pas le propriétaire.
La majorité des failles du Top 10 OWASP (broken access control, injection, XSS, auth cassée…) se jouent dans le code applicatif — donc dans le tien. Personne d’autre n’est mieux placé que le dev qui écrit la fonctionnalité pour :
- Vérifier qu’un utilisateur ne peut accéder qu’à ses données.
- Paramétrer une requête au lieu de la concaténer.
- Encoder une sortie avant de l’injecter dans une page.
- Ne pas mettre un secret dans une variable exposée au client.
Ces gestes ne sont pas « en plus » du dev : ils sont le dev, bien fait.
🛡️ La parade — Traite la sécurité comme tu traites déjà les tests et la lisibilité : un attribut de qualité du code, présent à chaque PR, pas une phase séparée. Une fonctionnalité qui « marche » mais laisse un utilisateur lire les données d’un autre n’est pas « finie avec un bug de sécu » — elle n’est pas finie.
La bonne nouvelle : c’est apprenable
Si ce chapitre insiste sur les risques, ce n’est pas pour faire peur — c’est pour justifier l’investissement. Car voici le vrai message du cours : la sécurité applicative n’est pas un art obscur. Chaque grande attaque a un mécanisme mécanique, compréhensible en quelques minutes, et une parade précise, souvent quelques lignes ou une bonne API.
Une injection SQL, c’est « une entrée traitée comme du code » → parade : « paramétrer ». Un XSS, c’est « une entrée réfléchie dans le HTML » → parade : « encoder en sortie ». Un IDOR, c’est « pas de vérification du propriétaire » → parade : « vérifier côté serveur ». Tout le cours est construit sur ce couple mécanisme / parade. À la fin, tu ne réagiras plus à la sécurité comme à une corvée floue, mais comme à un ensemble de réflexes concrets.
🧭 Sur FormaCampus — FormaCampus, notre EdTech fil rouge, héberge des données d’apprenants : identités, résultats, parfois des informations sur des situations de handicap. Pour un attaquant automatisé, c’est une base d’emails et de données personnelles monétisables — peu importe que ce soit « juste une plateforme de formation ». Une fuite, ici, c’est une violation RGPD et la fin de la confiance des établissements clients. Tout au long du cours, on la sécurise comme si elle était visée, parce qu’en pratique, elle l’est.
✏️ Exercices
Exercice 1 — Démonte l’objection. Un collègue met en ligne un prototype interne « accessible à personne, juste pour la démo de vendredi » et refuse d’ajouter la moindre auth « parce que personne ne connaît l’URL ». Donne-lui deux raisons concrètes pour lesquelles c’est risqué.
✅ Solution
(1) Les attaques sont automatisées et indiscriminées : des bots scannent les plages d’IP et testent des chemins courants (/.env, /admin, /.git) sans connaître l’URL « secrète » ni se soucier de ce que fait l’appli. Une appli exposée est sondée en quelques minutes. (2) L’obscurité n’est pas une protection : « personne ne connaît l’URL » n’est pas un contrôle d’accès — l’URL peut fuir (logs de proxy, referer, historique, partage), et le prototype manipule sans doute déjà des données réelles. Il faut au minimum une authentification et ne pas exposer de données sensibles.
Exercice 2 — Classe le coût. Range ces quatre découvertes d’une même faille d’accès (un apprenant peut lire les notes d’un autre) du moins au plus coûteux : (a) un pentest trois jours avant la prod, (b) une revue de code sur la PR, (c) un journaliste qui publie la fuite, (d) une réflexion d’archi au moment de concevoir l’API.
✅ Solution
Du moins au plus coûteux : (d) design → (b) revue de code → (a) pentest pré-prod → (c) fuite publique. Plus la découverte est proche de la conception, moins la correction coûte ; une fuite exploitée et médiatisée (incident réel) est de loin la plus chère (données exposées, RGPD, réputation, remédiation). C’est l’argument du shift-left.
🧠 Quiz de révision
1. Pourquoi « mon appli est trop petite pour être attaquée » est-il un raisonnement faux ?
Parce que la plupart des attaques sont automatisées et indiscriminées : des bots scannent Internet et exploitent toute faiblesse trouvée, sans choisir ni évaluer la cible. Même une petite appli a de la valeur (données, ressources de calcul, pivot, rançon). On n’a pas besoin d’être visé pour être victime.
2. Qu’est-ce que le « shift-left » en sécurité ?
Déplacer l’effort de sécurité vers le début du cycle de développement (conception, code) plutôt que la fin (pentest, prod). Motif : une faille coûte exponentiellement moins cher à corriger tôt. Une faille non écrite est gratuite à corriger.
3. Cite trois choses qu’un attaquant tire d’une appli « sans intérêt ».
Par exemple : des données (emails, mots de passe réutilisables, PII revendables), une ressource de calcul (minage, spam, phishing, relais), un pivot vers d’autres systèmes, ou un levier de rançon (ransomware). La valeur pour l’attaquant est indépendante de ce que fait l’appli.
4. Pourquoi la sécurité ne peut-elle pas être entièrement déléguée aux ops ou au pentest final ?
Parce que la majorité des failles (broken access control, injection, XSS, auth…) se jouent dans le code applicatif que le dev écrit. Un ops durcit l’infra mais ne peut pas deviner qu’un endpoint ne vérifie pas le propriétaire ; un pentest trouve des failles mais ne réécrit pas l’appli. Le dev est le mieux placé pour les empêcher.
5. En une phrase, quelle est la structure pédagogique de tout le cours ?
Le couple mécanisme / parade : pour chaque famille d’attaque, on explique comment elle marche (le mécanisme), puis comment on la ferme (la parade, souvent quelques lignes ou une bonne API). La sécurité devient un ensemble de réflexes concrets, pas une peur floue.
Chapitre suivant : CIA, surface d’attaque, defense-in-depth — les propriétés qu’on protège et les principes qui guident chaque décision.