Le threat modeling avec STRIDE est la technique la plus utilisée pour anticiper les menaces sur un système avant de l'avoir construit. En 45 minutes de refinement, une équipe identifie des failles architecturales que les outils automatiques ne détecteront jamais, parce que ce sont des choix de conception, pas des bugs de code. Ce guide s'adresse aux équipes DevSecOps qui veulent intégrer STRIDE au quotidien, pas seulement le connaître en théorie : méthode en 4 étapes, identification des actifs, exemple complet sur une API JWT couvrant les 6 catégories de menaces, priorisation, abuse cases et exigences testables, place des outils assistés par IA, intégration au backlog agile, et un mini-projet pour produire votre propre modèle de menace.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre les 6 catégories STRIDE et le contrôle technique associé à chacune
- Conduire une session de threat modeling en 4 étapes chronométrées
- Identifier les actifs à protéger et les frontières de confiance sur un Data Flow Diagram (DFD) minimal
- Appliquer STRIDE de bout en bout sur un exemple réaliste d'API d'authentification
- Situer la place des outils assistés par IA dans la démarche, sans leur déléguer la décision
- Traduire les menaces en abuse cases, en exigences de sécurité testables et en vérifications CI/CD
Pourquoi STRIDE et pas autre chose
Section intitulée « Pourquoi STRIDE et pas autre chose »STRIDE est simple à enseigner, simple à appliquer en équipe et couvre les menaces les plus courantes dans les systèmes web et Cloud Native. Ses 6 catégories correspondent directement à des contrôles techniques que les développeurs connaissent déjà, ce qui évite d'introduire un vocabulaire de sécurité déconnecté du code.
| Lettre | Catégorie | Contre quoi | Contrôle associé |
|---|---|---|---|
| S | Spoofing | Usurpation d'identité | Authentification forte |
| T | Tampering | Altération de données | Intégrité, signatures |
| R | Repudiation | Non-traçabilité des actions | Journalisation, audit trails |
| I | Information Disclosure | Exposition de données sensibles | Chiffrement, contrôle d'accès |
| D | Denial of Service | Indisponibilité | Rate limiting, circuit breakers |
| E | Elevation of Privilege | Escalade de droits | Moindre privilège, RBAC |
Le Threat Modeling Manifesto, référence citée par la fiche threat modeling de l'OWASP, résume toute démarche à 4 questions : sur quoi travaillons-nous, qu'est-ce qui peut mal tourner, que faisons-nous à ce sujet, et avons-nous fait du bon travail. Les 4 étapes détaillées plus loin répondent directement à ces questions, dans un format chronométré adapté au rythme d'un sprint.
Quand utiliser STRIDE : idéal pour les nouvelles fonctionnalités, les changements d'architecture ou les intégrations avec des systèmes externes. Pas pour auditer du code déjà en production : les scanners de code statique (SAST, pour Static Application Security Testing) font mieux pour ça.
Les 4 étapes d'une session de threat modeling
Section intitulée « Les 4 étapes d'une session de threat modeling »Une session efficace suit toujours le même déroulé, qu'elle dure 30 minutes ou une demi-journée. Le chronométrage ci-dessous correspond à une feature de taille moyenne en refinement ; il se multiplie pour un changement d'architecture complet.
-
Décrire le système : lister les actifs à protéger, puis construire un Data Flow Diagram (DFD) simple avec composants, flux de données et limites de confiance (trust boundaries). 10 minutes.
-
Identifier les menaces STRIDE : pour chaque flux et chaque composant, poser la question : quelles catégories STRIDE s'appliquent ici ? 20 minutes.
-
Évaluer et prioriser : pour chaque menace identifiée, estimer la probabilité et l'impact sur une grille simple Critique/Élevé/Moyen/Faible, détaillée plus bas. 10 minutes.
-
Décider des mitigations : accepter, corriger, transférer. Les corrections deviennent des exigences de sécurité testables et des user stories dans le backlog. 10 minutes.
Que protège-t-on ? Identifier les actifs
Section intitulée « Que protège-t-on ? Identifier les actifs »Un actif est ce dont la compromission ferait du tort : une donnée, un secret, une capacité ou une trace. On le liste avant de chercher les menaces, parce que c'est lui qui donne son poids à chacune : une menace qui n'atteint aucun actif important passe en bas de la pile. C'est la première des quatre questions du Threat Modeling Manifesto, « sur quoi travaillons-nous ? », appliquée à ce qui compte vraiment.
| Type d'actif | Question à poser | Exemple sur une API d'authentification |
|---|---|---|
| Données | Quelles données une fuite exposerait-elle ? | La base des utilisateurs, avec les empreintes de mots de passe |
| Secrets | Quelle clé donnerait tout le reste ? | La clé privée qui signe les jetons JWT |
| Capacités | Quel service ne doit pas s'arrêter ? | La disponibilité de l'endpoint de connexion |
| Traces | Que faudra-t-il prouver après un incident ? | Le journal d'audit des actions sensibles |
Sur cet exemple, la clé de signature domine : qui la détient fabrique des jetons valides pour n'importe quel compte, et toutes les autres protections tombent. Elle mérite donc la première place dans la session, avant même la base des utilisateurs.
Template de DFD minimal
Section intitulée « Template de DFD minimal »Vous n'avez pas besoin d'un outil dédié pour démarrer. Un tableau blanc ou un Miro suffit largement pour la première session. Ce qui compte, c'est de représenter clairement les éléments qui traversent une frontière de confiance, pas de produire un schéma esthétique.
Un DFD utile fait apparaître :
- Les acteurs (utilisateur, service externe, admin)
- Les composants (application, base de données, cache, queue)
- Les flux de données (requêtes HTTP, appels SQL, messages)
- Les limites de confiance, lignes qui marquent la frontière entre zones de confiance différentes
[Utilisateur] --HTTPS--> [API Gateway] --appel interne--> [Service Auth] | | trust boundary [Base de données] | [Service Profil] --> [Base de données]Une limite de confiance (trust boundary) passe partout où le niveau de confiance change : entre Internet et la passerelle d'API, entre un service et sa base de données, entre le pipeline CI et la production. Chaque flux qui franchit une limite de confiance est candidat à une analyse STRIDE. Un flux interne entre deux composants qui se font mutuellement confiance mérite moins d'attention qu'un flux qui traverse la frontière entre l'utilisateur et votre système.
Exemple appliqué : API d'authentification
Section intitulée « Exemple appliqué : API d'authentification »Prenons une API d'authentification classique avec JWT (JSON Web Token, un jeton signé qui transporte l'identité de l'utilisateur). L'exemple suivant couvre les 6 catégories STRIDE sur ce même système, pour montrer qu'aucune catégorie ne doit être sautée par habitude.
Menace : Un attaquant usurpe l'identité d'un utilisateur en rejouant un token JWT expiré ou volé.
Questions à poser :
- Les tokens ont-ils une expiration courte (15 min) ?
- Les refresh tokens sont-ils révocables ?
- Y a-t-il une vérification de l'empreinte client (IP, user-agent) ?
Mitigation :
- JWT avec expiration courte et refresh token stocké en cookie
HttpOnly - Révocation des tokens via liste de blocage en mémoire
- Story backlog : "En tant que système, je dois invalider tous les tokens actifs d'un utilisateur sur demande ou détection d'anomalie"
Menace : Un attaquant modifie le payload du JWT pour s'octroyer des rôles supplémentaires.
Questions à poser :
- L'algorithme de signature est-il robuste (RS256 ou ES256) ?
- L'API rejette-t-elle les tokens avec
alg: none? - La clé de signature est-elle bien protégée ?
Mitigation :
- Forcer RS256, rejeter tout autre algorithme
- Secret géré dans un gestionnaire de secrets avec rotation automatique
- Test d'intégration : vérifier que
alg: noneest rejeté
Menace : Un utilisateur nie avoir modifié son adresse e-mail ou initié une action sensible, faute de traçabilité fiable des appels effectués via l'API.
Questions à poser :
- Chaque action sensible (changement de mot de passe, suppression de compte) est-elle journalisée avec un horodatage ?
- Les logs d'audit sont-ils protégés contre une altération a posteriori ?
- L'auteur de l'action est-il lié de façon fiable au token utilisé au moment de l'action ?
Mitigation :
- Audit trail en écriture seule pour les actions sensibles, avec horodatage et identifiant de session
- Hachage chaîné des entrées de log pour détecter toute altération
- Story backlog : "En tant qu'utilisateur, je dois pouvoir consulter l'historique des actions effectuées sur mon compte"
Menace : Les messages d'erreur exposent le nom d'utilisateur dans les logs : "Mot de passe incorrect pour user@company.com".
Questions à poser :
- Les réponses d'erreur sont-elles génériques côté client ?
- Les logs de production contiennent-ils des données personnelles ou des credentials ?
- Les tokens apparaissent-ils dans les URLs (et donc dans les logs de proxy) ?
Mitigation :
- Réponse unique : "Identifiants incorrects" sans préciser lequel
- Règle de lint dans le pipeline : interdire les patterns
password=,token=,secret=dans les logs - Story backlog : "En tant que développeur, je dois utiliser un logger wrapper qui masque les champs sensibles"
Menace : Un attaquant sature l'endpoint de connexion avec des tentatives de credential stuffing (essais automatisés d'identifiants volés), rendant le service indisponible pour les utilisateurs légitimes.
Questions à poser :
- Existe-t-il une limite de débit (rate limiting) par IP et par compte sur les endpoints d'authentification ?
- Un circuit breaker (un mécanisme qui coupe automatiquement les appels vers un service en train de saturer, pour éviter que la panne se propage) protège-t-il la base de données en cas d'afflux de requêtes ?
- Les tentatives échouées déclenchent-elles un verrouillage temporaire ?
Mitigation :
- Rate limiting par IP et par identifiant de compte, avec backoff progressif
- Détection de credential stuffing via un service de réputation d'IP
- Story backlog : "En tant que système, je dois bloquer temporairement un compte après plusieurs échecs de connexion rapprochés"
Menace : Un utilisateur standard accède à des endpoints admin en manipulant l'URL ou les paramètres.
Questions à poser :
- Les rôles sont-ils vérifiés côté serveur (pas seulement côté client) ?
- Les IDs de ressources sont-ils vérifiables côté serveur (pas de BOLA, Broken Object Level Authorization, la faille qui permet d'accéder aux données d'un autre utilisateur en changeant simplement un identifiant dans l'URL) ?
- L'API a-t-elle un modèle de permissions documenté ?
Mitigation :
- Autorisation vérifiée sur chaque endpoint, pas seulement au login
- UUIDs non séquentiels pour les IDs exposés
- Test d'autorisation systématique dans les tests d'intégration
Prioriser : quelles menaces traiter en premier ?
Section intitulée « Prioriser : quelles menaces traiter en premier ? »Une session produit souvent une quinzaine de menaces, et l'équipe ne peut pas toutes les traiter dans le sprint. On les classe en croisant probabilité et impact sur l'actif touché, avec la même logique que la leçon Menace, risque, vulnérabilité. Une grille à quatre niveaux suffit, à condition d'associer à chacun une décision et un délai plutôt qu'un simple score.
| Niveau | Quand | Décision |
|---|---|---|
| Critique | Impact fort sur un actif majeur, exploitation plausible | Mitigation avant la mise en production |
| Élevé | Impact fort mais exploitation difficile, ou l'inverse | Story de sécurité dans le sprint suivant |
| Moyen | Impact limité, exploitation plausible | Backlog de sécurité, revue au prochain refinement |
| Faible | Impact limité et exploitation improbable | Risque accepté explicitement, noté dans le ticket |
La grille DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) note chaque menace sur cinq critères. Elle reste répandue, mais Microsoft, qui l'avait créée, l'a abandonnée dès 2008 : deux évaluateurs donnaient des notes très différentes à la même menace. Une grille courte, discutée en équipe et reliée à une décision, produit un classement plus stable qu'un score à cinq décimales.
Écrire des abuse cases
Section intitulée « Écrire des abuse cases »Un abuse case est une user story écrite du point de vue de l'attaquant : « en tant qu'attaquant, je veux… afin de… ». Il transforme une menace STRIDE abstraite en scénario concret, compréhensible par toute l'équipe, et il se teste. Là où la user story décrit ce que le système doit permettre, l'abuse case décrit ce qu'il doit empêcher.
| Menace STRIDE | Abuse case | Ce que le test vérifie |
|---|---|---|
| Spoofing | En tant qu'attaquant, je veux rejouer un jeton volé après la déconnexion de sa victime, afin d'accéder à son compte | Un jeton révoqué est refusé |
| Tampering | En tant qu'attaquant, je veux envoyer un jeton signé avec alg: none, afin de m'attribuer le rôle admin | La requête est rejetée avec une erreur 401 |
| Elevation of Privilege | En tant qu'utilisateur standard, je veux changer l'identifiant dans l'URL, afin de lire le profil d'un autre client | La requête est rejetée avec une erreur 403 |
Chaque abuse case retenu devient un test d'intégration qui doit échouer côté attaquant : c'est ce qui empêche une régression de rouvrir la faille six mois plus tard, quand plus personne ne se souvient de la session.
Des menaces aux exigences de sécurité
Section intitulée « Des menaces aux exigences de sécurité »Une mitigation décidée en séance reste une intention tant qu'elle n'est pas écrite comme une exigence : une phrase vérifiable, avec un critère d'acceptation. « Sécuriser les jetons » ne se teste pas ; « un jeton expire au bout de 15 minutes et un jeton révoqué est refusé » se teste. C'est cette forme qui entre dans la Definition of Done et dans le pipeline.
Le schéma ci-dessous suit une seule menace de bout en bout, le jeton altéré de la catégorie Tampering : elle devient un abuse case, puis une exigence testable, puis un test d'intégration joué à chaque build.
| Menace | Exigence de sécurité | Vérification |
|---|---|---|
| Jeton rejoué (S) | Les jetons d'accès expirent en 15 minutes ; la révocation est effective immédiatement | Test d'intégration sur un jeton révoqué |
| Jeton altéré (T) | Seul l'algorithme RS256 est accepté ; tout autre algorithme est refusé | Test qui envoie alg: none |
| Fuite dans les logs (I) | Aucun mot de passe, jeton ou secret n'apparaît dans les journaux | Scanner de secrets et règle de lint en CI |
| Saturation du login (D) | Au-delà de 5 échecs en une minute, le compte est verrouillé temporairement | Test de charge sur l'endpoint |
Pour ne pas réinventer chaque exigence, l'OWASP ASVS (Application Security Verification Standard), dont la version 5.0 est parue le 30 mai 2025, fournit un catalogue d'exigences vérifiables classées par niveau. On y pioche celles qui couvrent les menaces retenues, plutôt que de tout appliquer d'un bloc.
Intégrer le threat modeling dans le flux agile
Section intitulée « Intégrer le threat modeling dans le flux agile »Le threat modeling n'a pas besoin d'être un processus lourd pour produire de la valeur. L'enjeu est de le répéter souvent, en petit format, plutôt que d'organiser un grand exercice annuel vite oublié.
Dans le refinement (recommandé)
Section intitulée « Dans le refinement (recommandé) »Lors du refinement d'une user story qui introduit un nouveau flux de données ou une nouvelle intégration, ajoutez 10 à 15 minutes de threat modeling :
- Dessinez le DFD du flux impacté au tableau
- Passez les 6 lettres STRIDE en 2 minutes chacune
- Notez les menaces identifiées
- Créez les stories de sécurité associées dans le même sprint ou dans le backlog de sécurité
Dans la Definition of Done
Section intitulée « Dans la Definition of Done »Ajoutez un critère dans votre Definition of Done (DoD, l'ensemble des conditions qu'une story doit remplir pour être considérée terminée) pour les features qui touchent des données sensibles ou des accès :
- [ ] Threat modeling STRIDE réalisé et documenté dans le ticket- [ ] Menaces critiques mitigées ou acceptées explicitement- [ ] Stories de sécurité créées pour les mitigations non urgentesLors de la conception d'architecture
Section intitulée « Lors de la conception d'architecture »Pour les changements d'architecture (nouvelle intégration, nouveau service), organisez une session dédiée de 90 minutes : 20 minutes pour construire le DFD ensemble, 40 minutes pour parcourir STRIDE (5 minutes par catégorie, 2 séquences), 20 minutes pour prioriser et décider, et 10 minutes pour documenter dans l'ADR (Architecture Decision Record, un document court qui trace une décision d'architecture et son contexte).
Les erreurs courantes à éviter
Section intitulée « Les erreurs courantes à éviter »Threat modeling assisté par IA : accélérateur, pas remplaçant
Section intitulée « Threat modeling assisté par IA : accélérateur, pas remplaçant »Depuis 2023, des outils assistés par IA générative accélèrent la première étape du threat modeling : la génération d'une liste de menaces STRIDE à partir d'une description d'architecture. STRIDE GPT, projet open source qui s'appuie sur des modèles de langage, transforme en quelques minutes une description texte ou un dépôt GitHub en un premier jet de menaces, de scores de risque et de tests à écrire, sous des formats exploitables comme Markdown ou SARIF (Static Analysis Results Interchange Format, un format JSON standardisé pour échanger des résultats d'analyse entre outils de sécurité). Des éditeurs commerciaux comme IriusRisk ou ThreatModeler ont ajouté des fonctionnalités comparables à leurs catalogues de menaces.
Ces outils ne remplacent pas la session collaborative. Un modèle de langage qui reçoit une description vague produit des menaces génériques, sans lien avec les vraies limites de confiance du système, et peut passer à côté d'un flux critique que l'équipe connaît par cœur. La pratique qui se stabilise en 2026 consiste à utiliser l'IA comme générateur de brouillon et validateur de complétude (a-t-on bien couvert les 6 catégories sur chaque flux sensible), puis à laisser l'équipe trancher la priorisation et les mitigations. Le projet TaaC-AI, référencé par la fiche threat modeling de l'OWASP, suit la même logique de threat modeling as code enrichi par un modèle de langage.
Des extensions académiques comme STRIDE-AI adaptent la grille aux systèmes d'IA générative et aux agents autonomes, avec des catégories de menaces propres à ces systèmes (empoisonnement de modèle, injection de prompt). Ces extensions restent expérimentales et ne concernent pas la majorité des équipes qui appliquent STRIDE à des API classiques.
Quand passer d'un tableau blanc à un outil dédié ?
Section intitulée « Quand passer d'un tableau blanc à un outil dédié ? »Le DFD au tableau et les post-its colorés (un par catégorie STRIDE) suffisent pour les premières sessions, celles où l'équipe apprend encore la méthode. Ce qui compte à ce stade, c'est la conversation que génère l'exercice, pas le rendu final : un schéma imparfait mais discuté vaut mieux qu'un diagramme soigné produit seul dans son coin.
Le passage à un outil dédié devient pertinent quand deux signaux apparaissent ensemble : l'équipe maîtrise déjà les 4 étapes sans les relire, et le volume de sessions augmente (plusieurs par sprint, sur des systèmes qui partagent des composants). Des outils open source comme OWASP Threat Dragon permettent alors de conserver un historique des DFD et des menaces d'une session à l'autre, et des outils assistés par IA (voir plus haut) peuvent générer un premier jet de menaces à partir de ce DFD, sans dispenser l'équipe de la discussion finale.
Du threat modeling au pipeline CI/CD
Section intitulée « Du threat modeling au pipeline CI/CD »Le threat modeling identifie des risques de conception. Beaucoup de ces risques peuvent être traduits en vérifications automatiques dans le pipeline CI/CD (intégration et déploiement continus), ce qui transforme une décision ponctuelle en garde-fou permanent.
Exemples de traductions :
| Menace STRIDE | Type de vérification automatisable |
|---|---|
| Secrets exposés dans les logs (I) | Scanner de secrets dans le code |
| Dépendances avec vulnérabilités connues (T/I) | Analyse des composants (SCA, Software Composition Analysis) |
| Headers de sécurité absents (I) | Tests de sécurité dynamiques (DAST, Dynamic Application Security Testing) |
| Endpoint sans authentification (S/E) | Tests d'intégration d'autorisation |
| Absence de rate limiting (D) | Tests de charge sur les endpoints sensibles |
| Processus exécuté sans isolation (E) | Analyse statique de configuration |
Chacune de ces vérifications relève d'une famille de tests de sécurité automatisés : SAST pour le code, SCA pour les dépendances, DAST pour l'application qui tourne.
Mettre en pratique : le modèle de menace du fil rouge
Section intitulée « Mettre en pratique : le modèle de menace du fil rouge »Cette leçon se termine par un mini-projet, première preuve de la formation : produire le modèle de menace de l'application du fil rouge, ou à défaut d'une petite application que vous connaissez, une API avec sa base de données et son pipeline. Il ne se note pas automatiquement, mais il se relit avec la liste de contrôle ci-dessous, et il sert de référence pour tous les modules suivants.
# Modèle de menace : <nom de l'application>
## 1. Actifs| Actif | Type | Pourquoi il compte |
## 2. Diagramme de flux<DFD : acteurs, composants, flux, limites de confiance>
## 3. Menaces STRIDE| Flux ou composant | Catégorie | Menace | Actif touché |
## 4. Priorisation| Menace | Probabilité | Impact | Niveau | Décision |
## 5. Abuse cases et exigences| Menace | Abuse case | Exigence testable | Vérification |Le livrable est recevable quand chaque flux qui franchit une limite de confiance a été passé sur les six catégories, que chaque menace critique porte une décision (corriger, accepter, transférer), et que chaque correction s'exprime en exigence testable. Un risque accepté porte un nom et une date de réexamen, sinon il n'est pas accepté, il est oublié.
À retenir
Section intitulée « À retenir »- STRIDE est efficace en 30 à 60 minutes. Plus long, c'est qu'on cherche à tout modéliser, ce n'est pas le but.
- Les 6 catégories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) couvrent la majorité des menaces des systèmes web et Cloud Native.
- Les résultats d'un threat modeling se traduisent en user stories de sécurité, pas en documents PDF.
- Commencez par les actifs et les flux qui franchissent les limites de confiance : c'est là que les risques sont les plus élevés.
- Chaque menace retenue devient une exigence de sécurité testable, un abuse case, puis une vérification automatisée ; DREAD, abandonnée par Microsoft pour sa subjectivité, n'est pas indispensable pour prioriser.
- Un threat modeling sans décision est un coût sans valeur.
- Les outils assistés par IA accélèrent le brouillon de menaces, mais la priorisation reste une décision d'équipe.
- Traduisez les menaces en vérifications CI/CD pour transformer une décision ponctuelle en garde-fou permanent.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Moindre privilège
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Ces réponses courtes reprennent les questions qui reviennent le plus souvent sur STRIDE : sa différence avec DREAD, le déroulé d'une session et la place des outils IA. Chacune se lit seule.