De la conception d’une API POST /login à un Threat Model automatisé : ma démarche Security by Design avec STRIDE

Dans une démarche DevSecOps, cette étude présente l’application d’une approche de Threat Modeling sur une API afin d’intégrer la sécurité dès les phases de conception et de développement.

L'objectif était d'aller au-delà du développement fonctionnel et d'intégrer la sécurité dès la phase de conception (Security by Design).

L'analyse a suivi plusieurs étapes :

• Modélisation du système avec un DFD ;
• Identification des frontières de confiance ;
• Analyse des menaces avec STRIDE ;
• Construction d'arbres d'attaque ;
• Priorisation des risques ;
• Définition des mesures de mitigation ;
• Automatisation de la validation du modèle de menace.

Le système étudié est une API d'authentification basée sur un endpoint :

POST /login

Objectif

Cette API permet à un utilisateur de s'authentifier avec ses identifiants afin d'obtenir un accès au système.

Architecture simplifiée :

Avant d’identifier les vulnérabilités potentielles, nous avons commencé notre démarche de Threat Modeling par une question fondamentale :

Sur quoi travaillons-nous ?

Cette première étape consiste à comprendre le système étudié, ses composants, ses flux de données et les zones où le niveau de confiance change.

Pour cela, nous avons réalisé un Data Flow Diagram (DFD) de notre API d’authentification POST /login.

Identification des éléments du système

Nous avons identifié les principaux acteurs qui interagissent avec le système :

• Utilisateur : personne souhaitant s’authentifier auprès de l’application ;

• Administrateur : acteur disposant de privilèges spécifiques selon les fonctionnalités de l’application.

Les principaux composants techniques identifiés sont :

• Client / Navigateur : interface utilisée par l’utilisateur pour envoyer sa demande d’authentification ;

• API REST Flask : point d’entrée permettant de traiter les requêtes POST /login ;

• Service d’authentification : composant responsable de la vérification des informations d’identification ;

• Base utilisateurs : stockage contenant les informations nécessaires à l’authentification.

Lors du processus d’authentification, plusieurs données sensibles sont manipulées :

• Identifiants utilisateurs ;

• Mots de passe ;

• Tokens d’authentification ;

• Informations liées aux sessions.

La protection de ces données est essentielle afin de garantir la confidentialité et l’intégrité du système.

Dans un Threat Modeling, une Trust Boundary représente une frontière où le niveau de confiance change entre deux composants.

Nous avons identifié deux principales frontières de confiance.

1. Frontière Utilisateur / API

La première frontière se situe entre l’utilisateur et l’API.

Tout ce qui provient du client doit être considéré comme non fiable, car un attaquant peut potentiellement modifier les données envoyées.

Les risques associés sont notamment :

• Modification des requêtes ;

• Tentatives d’injection ;

• Usurpation d’identité ;

• Envoi de données malveillantes.

Des mécanismes de validation et de contrôle doivent donc être appliqués avant tout traitement.

2. Frontière API / Base de données

La seconde frontière concerne la communication entre l’application et la base de données.

La base utilisateurs contient des informations sensibles, notamment les données nécessaires à l’authentification.

Les mesures de protection identifiées sont :

• Contrôle strict des accès ;

• Validation des requêtes ;

• Protection des données sensibles ;

• Chiffrement des informations critiques ;

• Traçabilité des opérations importantes.

Cette modélisation nous permet d’avoir une vision claire de l’architecture de notre système avant de passer à l’étape suivante : l’identification des menaces avec la méthode STRIDE.

Le DFD constitue ainsi la base de notre analyse de sécurité, car il nous permet de savoir :

• où circulent les données ;

• quels composants sont critiques ;

• où se situent les frontières de confiance ;

• quelles zones nécessitent une attention particulière.

Après avoir compris l’architecture de notre système grâce au DFD, nous avons poursuivi notre démarche avec une deuxième question fondamentale du Threat Modeling :

Qu’est-ce qui peut mal tourner ?

L’objectif de cette étape est d’identifier les menaces potentielles qui pourraient compromettre la confidentialité, l’intégrité ou la disponibilité de notre API d’authentification.

Pour cela, nous avons utilisé la méthode STRIDE.

STRIDE est une méthode d’analyse des menaces développée par Microsoft pour aider les équipes de sécurité et de développement à identifier les risques dès la conception d’un système.

Le principe est d’analyser les menaces selon six catégories correspondant aux différentes propriétés de sécurité qu’un attaquant pourrait compromettre :

Nous avons analysé chaque catégorie STRIDE afin d’identifier les menaces possibles sur notre processus d’authentification.

1. Spoofing — Usurpation d’identité

Un attaquant pourrait obtenir les identifiants d’un utilisateur et se connecter à sa place.

Exemples :

• vol de mot de passe ;

• phishing ;

• réutilisation d’un mot de passe compromis.

• accès non autorisé au compte ;

• compromission de données personnelles.

Pour réduire ce risque, nous pouvons mettre en place :

• authentification multi-facteur (MFA) ;

• politique de mot de passe robuste ;

• expiration des sessions ;

• protection des tokens d’authentification.

2. Tampering — Altération des données

Un attaquant pourrait modifier une requête envoyée à l’API afin de contourner les contrôles.

Exemples :

• modification des paramètres envoyés ;

• manipulation des données utilisateur.

• authentification incorrecte ;

• comportement inattendu de l’application.

Mesures appliquées :

• validation des entrées côté serveur ;

• contrôle du format des données ;

• utilisation de requêtes sécurisées ;

• vérification des permissions.

3. Repudiation — Répudiation

Un utilisateur pourrait nier avoir effectué une action si aucune trace fiable n’existe.

Exemples :

• absence de logs de connexion ;

• journalisation insuffisante.

• difficulté d’investigation après incident ;

• absence de preuve numérique.

Nous mettons en place :

• journalisation des événements d’authentification ;

• horodatage des actions ;

• conservation sécurisée des logs.

4. Information Disclosure — Divulgation d’informations

Des informations sensibles pourraient être exposées.

Exemples :

• fuite de mots de passe ;

• messages d’erreur trop détaillés ;

• exposition d’informations utilisateurs.

• compromission des comptes ;

• violation de confidentialité.

Mesures recommandées :

• chiffrement des données sensibles ;

• stockage sécurisé des mots de passe avec un algorithme de hashage adapté ;

• réponses API minimales ;

• limitation des informations retournées en cas d’erreur.

5. Denial of Service — Déni de service

Un attaquant pourrait envoyer un grand nombre de requêtes vers l’endpoint POST /login.

Exemple :

• attaque brute force ;

• saturation du service.

• indisponibilité de l’application ;

• dégradation des performances.

Solutions possibles :

• limitation du nombre de requêtes (Rate Limiting) ;

• blocage temporaire après plusieurs échecs ;

• surveillance des comportements suspects.

6. Elevation of Privilege — Élévation de privilèges

Un utilisateur pourrait tenter d’obtenir des droits supérieurs à ceux qui lui sont attribués.

Exemple :

• modification d’un rôle utilisateur ;

• accès à une fonctionnalité administrateur.

• compromission complète de l’application ;

• accès à des données sensibles.

Mesures de protection :

• contrôle des autorisations côté serveur ;

• séparation des rôles ;

• principe du moindre privilège ;

• vérification systématique des permissions.

Après l’identification des menaces avec STRIDE, nous avons cherché à comprendre comment un attaquant pourrait concrètement atteindre son objectif.

Pour cela, nous avons utilisé un Attack Tree (arbre d’attaque).

Qu'est-ce qu'un Attack Tree ?

Un Attack Tree est une méthode de modélisation permettant de représenter les différents chemins possibles qu’un attaquant peut suivre pour atteindre un objectif.

Le principe est simple :

• Le nœud racine représente l’objectif de l’attaquant ;
• Les branches représentent les différentes stratégies possibles ;
• Les feuilles représentent les actions ou conditions nécessaires pour réussir l’attaque.

Les opérateurs logiques utilisés sont :

• OU (OR) : l’attaquant peut atteindre son objectif par l’une des méthodes disponibles ;
• ET (AND) : plusieurs conditions doivent être réunies pour réussir l’attaque.

Dans notre cas, l'objectif étudié est :

Obtenir un accès non autorisé à un compte utilisateur via l’API POST /login.

Les principaux chemins identifiés sont :

1. Voler les identifiants d’un utilisateur ;
2. Contourner le mécanisme d’authentification ;
3. Exploiter une mauvaise gestion des privilèges.

Cette approche permet de :

• mieux comprendre les scénarios d’attaque réels ;
• identifier les points faibles du système ;
• définir des protections adaptées ;
• prioriser les mesures de sécurité.

Dans notre cas, l’Attack Tree nous aide à passer d’une simple liste de menaces STRIDE à une vision plus réaliste des scénarios d’attaque.

Après avoir identifié les menaces, nous devons déterminer lesquelles traiter en priorité.

Toutes les vulnérabilités n’ont pas le même niveau de gravité.

Une faille très probable mais avec un impact limité peut être moins urgente qu’une faille rare capable de compromettre toute l’application.

Nous avons utilisé une approche classique :

Calcul du risque

[
Risque = Impact \times Probabilité
]

Impact

L’impact représente les conséquences possibles d’une attaque :

• faible : impact limité ;
• moyen : perturbation du service ;
• élevé : compromission de données ou du système.

Probabilité

La probabilité représente la facilité avec laquelle l’attaque peut être réalisée :

• faible : attaque difficile ;
• moyenne : nécessite certaines conditions ;
• élevée : attaque facilement réalisable.

Cette étape nous permet de concentrer les efforts de sécurité sur les risques les plus importants.

Dans une approche DevSecOps, la sécurité ne consiste pas seulement à corriger toutes les vulnérabilités, mais à :

• comprendre les risques ;
• mesurer leur importance ;
• traiter en priorité ceux qui présentent le plus grand danger pour le système.

La priorisation permet donc de prendre de meilleures décisions techniques et organisationnelles.

Après l’analyse Threat Modeling, nous avons mis en œuvre l’API d’authentification en intégrant les mesures de sécurité identifiées.

L’objectif était de créer une API fonctionnelle tout en appliquant une démarche Security by Design.

Avant de commencer l’analyse de sécurité, nous avons organisé les différents éléments nécessaires au développement et à la validation du Threat Model.

Pour cette démonstration, nous nous concentrons uniquement sur les fichiers essentiels :

• app.py : implémentation de l’API Flask POST /login ;
• requirements.txt : dépendances nécessaires au fonctionnement de l’application ;
• threats.yaml : formalisation des menaces identifiées avec STRIDE ;
• test_threats.py : tests automatisés de validation du modèle de menace.

Cette séparation permet de distinguer clairement :

• le code applicatif ;
• le modèle de sécurité ;
• les contrôles automatisés.

Nous avons développé une API d’authentification permettant de recevoir les identifiants d’un utilisateur et de vérifier son accès.

Le flux d’authentification est :

1. Réception des identifiants envoyés par le client ;
2. Validation des données reçues ;
3. Vérification auprès du service d’authentification ;
4. Retour d’une réponse.

Après le développement, nous avons lancé l’application localement afin de vérifier son fonctionnement.

Exécution :

python3 app.py

Puis test de l’endpoint :

Après l’analyse STRIDE, nous avons traduit les menaces identifiées dans un fichier threats.yaml.

Ce fichier devient une source exploitable par les outils d’automatisation.

Il contient :

• l’identifiant de la menace ;
• la catégorie STRIDE associée ;
• la description ;
• les mesures de mitigation.

Pour éviter qu’un Threat Model incomplet soit intégré au projet, nous avons créé un script Python utilisant Pytest.

Lancement :

pytest test_threats.py -v

Les contrôles réalisés :

• validité syntaxique YAML ;
• couverture des six catégories STRIDE ;
• nombre minimal de menaces ;
• présence des mesures de mitigation.

Enfin, les différents éléments du projet sont versionnés avec Git afin de conserver l’historique des modifications.

Cette mise en pratique illustre comment le Threat Modeling peut être intégré naturellement dans le cycle de développement d'une application.

Plutôt que de considérer la sécurité comme une étape réalisée uniquement avant la mise en production, nous l'avons intégrée dès les premières phases de conception et de développement.

Le processus suivi peut être résumé ainsi :

Grâce à cette démarche, les risques sont identifiés, documentés et vérifiés avant toute mise en production. L'automatisation permet également de garantir que le modèle de menace reste complet et cohérent au fil des évolutions du projet.

Cette approche s'inscrit pleinement dans une culture DevSecOps, où la sécurité est intégrée en continu tout au long du cycle de développement.

Cette mise en pratique permet de passer d'une approche théorique du Threat Modeling à son application sur une API que j'ai développée.

À travers cet exercice, j'ai appris à :

• comprendre l'architecture d'une application à l'aide d'un Data Flow Diagram (DFD) ;

• identifier les frontières de confiance (Trust Boundaries) ;

• analyser les menaces avec la méthode STRIDE ;

• construire des Attack Trees afin de représenter les différents scénarios d'attaque ;

• prioriser les risques en fonction de leur impact et de leur probabilité ;

• formaliser ces menaces dans un fichier threats.yaml ;

• automatiser leur validation avec Pytest dans une logique d'intégration continue.

Cette expérience m'a surtout permis de comprendre que la cybersécurité ne consiste pas uniquement à corriger des vulnérabilités après le développement.

Une approche moderne consiste à anticiper les risques dès la conception et à intégrer des mécanismes de sécurité tout au long du cycle de vie de l'application.

Le Threat Modeling apporte ainsi une méthode structurée pour répondre à quatre questions essentielles :

1. Sur quoi travaillons-nous ?

2. Qu'est-ce qui peut mal tourner ?

3. Quelles mesures mettons-nous en place pour réduire les risques ?

4. Avons-nous correctement traité les menaces identifiées ?

Au-delà de cet exercice, cette démarche constitue une compétence fondamentale pour les métiers de DevSecOps, Application Security, Cloud Security et Security Engineering. Elle montre qu'une sécurité efficace ne repose pas uniquement sur des outils, mais sur une analyse méthodique des risques et leur prise en compte dès les premières étapes du développement.