Chapitre 1.3 — Modéliser la menace (STRIDE)

⏱️ TL;DR — Sécuriser « au feeling », c’est colmater des trous au hasard en en laissant d’autres béants. La modélisation de menace (threat modeling) est la méthode qui structure la réflexion : on identifie les actifs (ce qui a de la valeur), on trace les frontières de confiance (où une donnée passe du fiable au non fiable), puis on applique STRIDE — six catégories de menaces (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) — pour ne rien oublier. Résultat : une liste priorisée de risques et de parades, avant d’écrire le code.

🎯 Objectifs

• Identifier les actifs d’une appli et leur valeur pour un attaquant.
• Tracer les frontières de confiance (trust boundaries) sur une architecture.
• Dérouler la méthode STRIDE pour énumérer les menaces d’un composant.
• Produire un mini modèle de menace exploitable (menace → parade).

Pourquoi modéliser, plutôt que réagir

Sans méthode, on sécurise ce qu’on connaît (« j’ai lu un article sur le XSS, je pense au XSS ») et on ignore le reste. La modélisation de menace inverse la démarche : au lieu de partir des attaques que tu connais, tu pars de ton système et tu te demandes systématiquement, pour chaque brique, ce qui peut mal tourner. C’est un exercice de conception, léger, qui se fait sur un tableau blanc avant de coder — ou en début de fonctionnalité.

Trois questions structurent tout modèle de menace :

1. Qu’est-ce qu’on protège ? (les actifs)
2. Qu’est-ce qui peut mal tourner ? (les menaces)
3. Qu’est-ce qu’on fait à ce sujet ? (les parades)

Étape 1 — Les actifs et les acteurs

Un actif est quelque chose qui a de la valeur : données personnelles, mots de passe, moyens de paiement, propriété intellectuelle, mais aussi la disponibilité du service ou la réputation. Lister les actifs, c’est savoir ce qu’un attaquant convoite — et donc où concentrer l’effort.

En face, on liste les acteurs : utilisateurs légitimes (aux droits variés), administrateurs, services externes, et bien sûr l’attaquant (externe anonyme, utilisateur authentifié malveillant, insider…). Un bon modèle considère que tout acteur peut être malveillant, y compris un utilisateur connecté.

Étape 2 — Les frontières de confiance

Une frontière de confiance (trust boundary) est l’endroit où une donnée passe d’une zone de confiance à une zone qui ne l’est pas (ou l’inverse). C’est là que les contrôles doivent se placer. La frontière la plus importante d’une appli web : entre le navigateur (jamais digne de confiance — l’utilisateur y contrôle tout) et le serveur.

Le principe fondateur : tout ce qui traverse une frontière de confiance depuis une zone non fiable doit être validé et autorisé. Le corps d’une requête, les paramètres, les en-têtes, même un champ « caché » d’un formulaire ou un prix envoyé par le client : côté serveur, tout cela est hostile. La validation faite dans le navigateur (JS) est une aide à l’UX, jamais une sécurité — l’attaquant contourne le front et parle directement à l’API.

⚠️ Piège — Le piège classique du dev front : croire qu’un contrôle fait côté client protège quoi que ce soit. Un champ disabled, une validation JavaScript, un prix calculé dans le navigateur, un rôle stocké dans le localStorage : tout cela est modifiable par l’utilisateur (DevTools, curl, proxy comme Burp). La sécurité vit de l’autre côté de la frontière, sur le serveur. Le client, c’est du confort, pas du contrôle.

Étape 3 — STRIDE : six façons dont ça tourne mal

Une fois les actifs et les frontières posés, STRIDE fournit une checklist de six catégories de menaces. Pour chaque composant ou flux, on passe les six et on se demande « est-ce applicable ici ? ». C’est ce qui évite les angles morts.

Concrètement, appliqué au login de FormaCampus :

• S — Bruteforce / credential stuffing pour se connecter comme quelqu’un d’autre → parade : hachage lent, rate limiting, MFA.
• T — Modifier le token de session pour changer d’identité → parade : session signée/opaque côté serveur.
• R — Un utilisateur nie avoir supprimé un cours → parade : logs d’audit horodatés.
• I — Le message d’erreur révèle si l’email existe (« mot de passe incorrect » vs « utilisateur inconnu ») → parade : message générique.
• D — Des milliers de tentatives saturent le service d’auth → parade : rate limiting, captcha après N échecs.
• E — Un apprenant accède à /admin → parade : autorisation vérifiée côté serveur sur chaque route.

💡 Réflexe — Tu n’as pas besoin d’un document de 40 pages. Un modèle de menace utile tient souvent sur une page : un schéma d’architecture avec les frontières de confiance, et pour chaque composant sensible, une passe STRIDE listant 2-3 menaces réalistes et leur parade. L’important n’est pas la forme, c’est d’avoir systématiquement posé la question « qu’est-ce qui peut mal tourner ici ? ».

Prioriser : tout n’est pas égal

Un modèle de menace liste plus de risques qu’on ne peut en traiter d’un coup. On priorise par le couple impact × probabilité : une élévation de privilège qui expose toutes les données (impact énorme, exploitation facile) passe avant un DoS théorique nécessitant des moyens colossaux. La modélisation ne vise pas le risque zéro (impossible) mais à dépenser l’effort là où il compte.

🧭 Sur FormaCampus — Avant de coder la fonctionnalité « un formateur exporte les résultats de sa classe », on fait une passe STRIDE de dix minutes. Elle révèle vite le risque majeur : Elevation of privilege / Information disclosure — un formateur pourrait-il exporter les résultats d’une autre classe en changeant un classId dans la requête ? (C’est un IDOR, qu’on verra en Partie 5.) La parade est identifiée avant d’écrire la requête : vérifier côté serveur que la classe demandée appartient bien au formateur connecté. Dix minutes de modélisation ont évité une fuite de données.

✏️ Exercices

Exercice 1 — Trace la frontière. Pour une appli Next.js avec des Server Actions qui écrivent en base, où se situe la frontière de confiance principale, et qu’est-ce que ça implique pour les données reçues par une Server Action ?

Exercice 2 — Passe STRIDE. Applique STRIDE à un endpoint POST /api/avis qui permet à un utilisateur connecté de publier un avis (texte libre) affiché à tous. Donne une menace plausible pour au moins quatre des six lettres.

🧠 Quiz de révision

Chapitre suivant : OWASP & l’état d’esprit — la boussole de la sécurité web et la bascule mentale « attaquant / défenseur ».