Les vulnérabilités IDOR (Insecure Direct Object Reference) figurent parmi les failles les plus fréquemment exploitées dans les applications bancaires en ligne. Dans une architecture microservices, elles prennent une dimension particulière : chaque service expose ses propres endpoints, gère ses propres identifiants d'objets, et les contrôles d'accès finissent par être réécrits à chaque itération. Le résultat est prévisible — des vérifications oubliées, des incohérences entre services, et une surface d'attaque qui s'élargit à mesure que le système grandit.
Pourquoi les contrôles ad hoc échouent systématiquement
L'approche classique consiste à ajouter une vérification dans chaque handler : "est-ce que l'utilisateur connecté est bien le propriétaire de ce compte ?". En pratique, cette logique est dupliquée dans le service des virements, dans celui des relevés, dans le service de gestion des bénéficiaires, et ainsi de suite. Dès qu'un développeur oublie un cas, ou qu'un nouveau service est branché sans relire les conventions existantes, une brèche apparaît.
Le problème n'est pas un manque de vigilance individuelle. C'est un problème d'architecture : quand la sécurité est traitée comme une responsabilité locale à chaque équipe, elle devient inconsistante par construction. Un attaquant qui teste méthodiquement les endpoints d'un système e-banking n'a besoin de trouver qu'un seul service mal configuré.
Le principe d'une couche d'autorisation centralisée
La réponse structurelle consiste à extraire toute la logique d'autorisation dans un composant dédié, souvent appelé policy engine. Ce moteur répond à une question unique et bien définie : "ce principal (utilisateur, service, token) est-il autorisé à effectuer cette action sur cet objet spécifique ?". Les microservices ne prennent plus de décision d'autorisation par eux-mêmes. Ils délèguent.
Dans un contexte e-banking, concrètement, le service de virements reçoit une requête pour initier un transfert depuis le compte ACC-00492. Avant toute logique métier, il interroge le policy engine en passant le JWT de l'utilisateur, l'action (initiate_transfer) et l'identifiant de la ressource. Le moteur vérifie la propriété de l'objet — et uniquement lui. Le service, lui, ne fait que consommer la réponse.
Les composants d'un policy engine adapté à l'e-banking
- Object ownership registry : un registre qui associe chaque identifiant de ressource (compte, carte, bénéficiaire) à son propriétaire canonique. Ce registre est la source de vérité, pas chaque base de données de chaque service.
- Un moteur d'évaluation de politiques, typiquement basé sur des standards comme OPA (Open Policy Agent) ou CASBIN, qui applique les règles de manière déclarative et auditée.
- Un middleware d'interception systématique, placé dans la couche API Gateway ou dans un SDK partagé par tous les services, pour garantir qu'aucune requête n'arrive au handler sans avoir été évaluée.
Vérification de la propriété de l'objet : les détails qui comptent
La vérification de propriété semble triviale jusqu'à ce qu'on confronte le modèle à la réalité d'un système bancaire. Plusieurs cas limites méritent une attention spécifique.
Premier cas : les objets partagés. Un compte joint appartient à plusieurs titulaires. La politique doit gérer des relations 1-to-many, avec des droits potentiellement asymétriques (consultation vs. virement). Second cas : la délégation. Un conseiller bancaire peut avoir un accès temporaire à certains comptes clients pour une opération donnée. Ce contexte doit être encodé dans le token ou dans une politique ad hoc, jamais hardcodé dans un service.
Troisième cas, souvent négligé : les identifiants indirects. Un endpoint qui accepte un transaction_id doit vérifier que la transaction appartient bien à un compte lui-même appartenant à l'utilisateur. La chaîne de propriété doit être remontée jusqu'à l'entité racine, pas seulement vérifiée au premier niveau.
Intégrer le contrôle IDOR dans la CI/CD
Une architecture centralisée ne vaut que si elle est testée en continu. Les tests de non-régression sur les IDOR doivent faire partie du pipeline, pas des audits ponctuels. Pour les équipes qui souhaitent structurer leur approche de tests de sécurité applicative dans leurs environnements d'entraînement, un catalogue de labs dédiés permet de valider ces scénarios dans des conditions réalistes.
Scénarios de tests à automatiser
- Tests de traversal horizontal : un utilisateur de test A tente d'accéder aux ressources d'un utilisateur de test B via tous les endpoints exposés. Le test échoue si une réponse 200 est retournée à la place d'un 403.
- Tests de traversal vertical : un utilisateur standard tente d'atteindre des ressources réservées aux administrateurs ou aux conseillers. Particulièrement critique pour les endpoints de consultation de solde agrégé ou de modification de limites.
- Tests d'identifiants séquentiels : si les IDs sont devinables (numériques, incrémentaux), le test doit vérifier que l'incrément ou le décrément d'un ID ne donne pas accès à une ressource non autorisée.
- Tests de bypass via paramètres alternatifs : certains endpoints acceptent des paramètres équivalents (IBAN en plus de l'ID interne). Chaque chemin d'accès à la ressource doit être couvert.
Ces tests peuvent être implémentés avec des frameworks comme pytest combiné à des fixtures de tokens JWT préconfigurés, ou intégrés directement dans des suites DAST légères (OWASP ZAP en mode API). L'essentiel est qu'ils s'exécutent à chaque pull request, pas seulement avant une mise en production.
Ce que cette architecture change pour les équipes SOC et sécurité
Pour un RSSI, la centralisation de l'autorisation offre un avantage souvent sous-estimé : l'auditabilité. Toutes les décisions d'accès passent par un point unique, ce qui signifie qu'un log structuré peut être produit systématiquement — avec l'identité du demandeur, la ressource ciblée, la politique appliquée et le résultat. En cas d'incident, la reconstruction de la séquence d'accès devient triviale.
Pour les équipes SOC qui surveillent ces logs, les anomalies deviennent détectables : un utilisateur qui génère un volume anormal de refus 403 sur des ressources variées est un signal clair d'une tentative d'énumération. Sans couche centralisée, ce signal est noyé dans les logs hétérogènes de dizaines de services différents. Les cas d'usage concrets en contexte e-banking et secteur financier montrent que cette centralisation réduit sensiblement le temps de détection de ce type d'attaque.
Questions fréquentes
Quelle est la différence entre un IDOR et une élévation de privilèges dans un contexte microservices ?
Un IDOR permet d'accéder à une ressource appartenant à un autre utilisateur du même niveau de privilège — c'est une violation de la propriété de l'objet. Une élévation de privilèges permet d'effectuer des actions réservées à un rôle supérieur. Les deux peuvent coexister et se combiner : un attaquant peut d'abord utiliser un IDOR pour accéder à un compte tiers, puis tenter une élévation via cet accès. C'est pourquoi les deux types de contrôle doivent être gérés par le même policy engine.
OPA est-il adapté à un contexte e-banking haute disponibilité ?
OPA peut être déployé en mode sidecar ou en cluster avec des instances multiples, ce qui lui permet de tenir des contraintes de latence faibles. Le point d'attention est le bootstrapping des politiques : elles doivent être versionnées, testées comme du code, et déployées de manière atomique avec les services qui en dépendent. Une politique mal migrée peut causer des refus d'accès légitimes en production, ce qui est le principal risque opérationnel à gérer.
Comment gérer la vérification de propriété pour des objets créés dynamiquement (ex : une nouvelle transaction) ?
L'objet ownership registry doit être alimenté au moment de la création de chaque ressource, dans la même transaction applicative que l'insertion en base. Si l'enregistrement de propriété échoue, la création de l'objet doit être annulée. Ce pattern garantit qu'aucun objet orphelin — non rattaché à un propriétaire — ne peut exister dans le système.
Les tests IDOR automatisés en CI/CD ne risquent-ils pas de ralentir les pipelines ?
Un test de traversal horizontal bien conçu sur un environnement d'intégration s'exécute en quelques secondes par endpoint. L'essentiel est de cibler les endpoints à risque élevé (ceux qui manipulent des identifiants de ressources financières) et de séparer la suite complète, exécutée sur une branche release, des tests critiques rapides sur chaque PR. Le coût en temps est largement inférieur à celui d'un incident en production.