Intégrez la sécurité dès la conception architecturale (A06:2025)
Vous avez accompli un travail de fond exceptionnel pour protéger le futur portail B2B de TechNova. En verrouillant les accès logiques aux ressources (A01), en durcissant l'infrastructure cloud (A02), en maîtrisant la chaîne d'approvisionnement (A03), en chiffrant les données (A04) et en neutralisant les injections de code (A05), vous avez érigé des barrières techniques particulièrement robustes.
Que se passe-t-il si la vulnérabilité ne vient pas d'un bug de code, mais de l'idée même de la fonctionnalité ?
Aujourd'hui, l'équipe produit de TechNova souhaite inclure une fonctionnalité métier complexe : un outil de géolocalisation en temps réel pour mettre en relation ses différents prestataires B2B. En analysant ce besoin, vous réalisez qu'un code parfaitement écrit, sans aucun bug technique, ne suffira pas à protéger les utilisateurs si la logique de la fonctionnalité est conceptuellement faillible.
C'est ici qu'intervient la catégorie A06 du Top 10 OWASP 2025 : le Défaut de Conception, ou Insecure Design. Cette catégorie démontre qu'une architecture défectueuse ne peut pas être corrigée par une implémentation parfaite. Votre nouvel objectif est d'ancrer définitivement la sécurité dans la dimension de l'architecture métier, en adoptant une approche Secure by Design. Vous allez instaurer une revue systématique des scénarios d'abus pour anticiper les pires comportements avant même l'écriture de la première ligne de code.
Analysez le cas public de vulnérabilité : Telegram
Pour bien faire la différence entre un problème de code et un problème de conception, il est particulièrement instructif d'analyser des incidents où la fonctionnalité a été utilisée exactement comme elle avait été pensée par ses créateurs, mais avec des intentions malveillantes.
Étudions le cas célèbre de la messagerie Telegram et de sa fonctionnalité "People Nearby" (Personnes à proximité). L'objectif initial était louable et parfaitement codé : permettre à un utilisateur de voir à quelle distance se trouvaient d'autres utilisateurs pour faciliter les rencontres. L'application affichait une information relative, par exemple "M. Dupont est à 500 mètres".
Comment un attaquant peut-il utiliser une simple indication de distance relative pour compromettre la sécurité physique d'un utilisateur sans pirater l'application ?
La réponse réside dans une technique mathématique simple : la trilatération.
Les attaquants n'ont exploité aucune faille technique. Ils ont simplement falsifié leurs propres coordonnées GPS (en utilisant des outils standards) pour se "placer" virtuellement à trois endroits différents sur la carte. En relevant la distance affichée par Telegram à partir de ces trois points distincts, ils ont pu calculer l'emplacement GPS exact et précis au mètre près de n'importe quel utilisateur.
Analysons un autre cas majeur : la vulnérabilité découverte sur TikTok par la société CheckPoint en 2020. L'application proposait une fonctionnalité légitime de "Recherche d'amis", qui permettait aux utilisateurs de lier leur carnet d'adresses pour trouver leurs contacts sur la plateforme. Là encore, le code fonctionnait exactement comme prévu. Cependant, des attaquants ont automatisé ce processus légitime pour soumettre des millions de numéros de téléphone générés aléatoirement. Ils ont ainsi pu créer une base de données massive reliant des numéros de téléphone réels aux pseudonymes et profils des utilisateurs, détournant totalement la fonctionnalité de son but initial.
Ces deux cas publics partagent un point commun fondamental : les développeurs ont codé le "chemin heureux" (l'utilisateur bienveillant qui cherche ses amis), mais personne n'a conçu de protection contre un usage abusif de la règle métier.
Identifiez les éléments clés de ce type de vulnérabilité
Maintenant que vous percevez l'impact d'une faille logique, vous devez comprendre comment l'OWASP structure la catégorie A06 (Insecure Design) afin de l'identifier dans vos propres projets de conception. L'OWASP souligne avec force qu'il faut différencier les défauts de conception des défauts d'implémentation. Ils ont des causes profondes différentes et nécessitent des remédiations distinctes.
L'élément clé majeur de cette vulnérabilité est le choix architectural défectueux lié à la logique métier.
Le deuxième élément clé est le manque d'anticipation des scénarios d'abus (ou misuse-cases). L'équipe produit a souvent un biais cognitif très fort : elle se concentre exclusivement sur les besoins de l'utilisateur légitime. Ce biais conduit inévitablement à l'absence de limites transactionnelles.
Par exemple, dans le cas d'un workflow de récupération de compte, une conception vulnérable inclurait l'utilisation de "questions secrètes" (quel est le nom de votre premier animal ?). L'OWASP Top 10 et les normes comme le NIST 800-63b interdisent formellement cette pratique conceptuelle. Une question secrète ne peut pas être considérée comme une preuve d'identité fiable, car n'importe quel attaquant peut trouver cette information en étudiant les réseaux sociaux de sa victime. Le code qui vérifie la réponse à la question secrète peut être parfait, la conception globale, elle, est désastreuse.
En identifiant ces failles logiques en amont, vous comprenez que la responsabilité de la sécurité ne repose plus uniquement sur les développeurs, mais s'étend aux chefs de produit, aux architectes et à tous les décideurs impliqués dans les spécifications.
Implémentez le processus de résolution pour éviter la vulnérabilité
Puisqu'un défaut de conception ne se résout pas avec une mise à jour de code technique, le processus de résolution que vous devez implémenter chez TechNova doit s'inscrire au cœur de votre méthode de travail. Vous devez intervenir dans les rituels de spécification pour instaurer des garde-fous avant même que le développement ne commence.
La pierre angulaire de ce processus est l'intégration systématique de la Modélisation des Menaces, ou Threat Modeling, pour chaque nouvelle fonctionnalité critique du portail.
Pour mettre en pratique ce processus de manière concrète dans votre cycle de développement (SDLC), vous devez exiger la rédaction systématique de cas d'abus. Dans les méthodes agiles, les équipes rédigent des "User Stories" pour décrire ce que l'utilisateur doit pouvoir faire. Vous allez exiger la rédaction d'"Abuse Stories" (ou misuse-cases) en parallèle.
Voici comment structurer votre démarche lors des sessions d'affinage (refinement sessions) :
Imaginez l'attaquant : Pour chaque fonctionnalité métier (comme la recherche, la réservation, ou la géolocalisation), forcez l'équipe à se mettre dans la peau d'un attaquant. Demandez-leur comment cette fonctionnalité pourrait être utilisée pour tricher, nuire à d'autres utilisateurs, ou coûter de l'argent à l'entreprise.
Intégrez des contrôles de plausibilité : Exigez que la conception inclue des garde-fous de bon sens à tous les niveaux (frontend et backend). Par exemple, si une action ne doit logiquement être effectuée qu'une fois par jour, l'architecture doit prévoir un système de limitation stricte (Rate Limiting ou Quotas).
Documentez les états d'échec : Les spécifications doivent définir clairement ce qu'est un comportement inattendu et comment le système doit réagir (bloquer l'action, alerter un administrateur) au lieu de le traiter silencieusement.
En intégrant la rédaction de ces scénarios malveillants à vos exigences, vous forcez les concepteurs du portail TechNova à intégrer des défenses métiers incontournables, rendant l'architecture résiliente aux manipulations logiques.
À vous de jouer
Contexte
La direction marketing de TechNova est très enthousiaste concernant le lancement prochain du portail B2B. Pour attirer un maximum de prestataires, elle propose une nouvelle fonctionnalité commerciale : la « réservation multiple d'équipements partagés ».
L'idée est simple et séduisante : pour simplifier la vie des professionnels, un prestataire pourra réserver à l'avance autant d'équipements qu'il le souhaite pour la semaine suivante, en quelques clics. Pour limiter les freins à l'utilisation lors de la période de lancement, le marketing insiste pour qu'aucun paiement initial ou dépôt de garantie ne soit demandé au moment de la réservation. Le prestataire paiera uniquement le jour où il viendra chercher l'équipement.
Fort de votre expertise sur la catégorie A06 (Insecure Design) et sur l'importance du Threat Modeling, vous analysez immédiatement cette proposition lors de la revue des spécifications. Vous constatez que cette conception n'envisage que le comportement d'un utilisateur honnête.
Consigne
Identifiez le scénario d'abus principal lié à cette logique métier défectueuse.
Ensuite, rédigez l'exigence de conception (le garde-fou architectural) que vous allez imposer au marketing et aux développeurs pour éviter ce contournement, tout en permettant au service de fonctionner.
En résumé
Différenciez la conception de l'implémentation : Un défaut de conception (A06) est une faille dans la logique métier ou l'architecture du logiciel ; un code parfait et sans bug ne pourra jamais corriger une fonctionnalité intrinsèquement mal pensée.
Anticipez les scénarios d'abus : Identifiez comment une fonctionnalité légitime (comme une recherche d'amis ou une réservation d'équipement) peut être automatisée ou détournée pour nuire au système.
Adoptez le Threat Modeling (Modélisation des Menaces) : Évaluez continuellement les risques en équipe en vous posant la question "Que pourrait-il se passer de mal ?" lors des phases de conception.
Rédigez des "Abuse Stories" : Accompagnez vos besoins utilisateurs (User Stories) de scénarios d'abus pour forcer l'intégration de limites transactionnelles et de contrôles de plausibilité avant le début du développement.
Vous êtes désormais capable d'intégrer la sécurité au cœur de vos réflexions architecturales en anticipant les failles logiques de votre produit, mais ces fondations résilientes ne suffiront pas si un attaquant parvient simplement à usurper l'identité de vos utilisateurs ; découvrons donc, dans le prochain chapitre, comment verrouiller la porte d'entrée principale de TechNova.
