Étude de cas : audit d'une plateforme d'échange de crypto-actifs

Chiffres clés

Contexte : que valait la sécurité d'un échange de crypto-actifs vu de l'intérieur ?

Une plateforme d'échange de crypto-actifs, soumise à des obligations de connaissance client (KYC), a demandé un audit externe en 2026. La question était simple : un utilisateur ordinaire peut-il voir, modifier ou déclencher quelque chose qui appartient à un autre utilisateur ?

La plateforme repose sur une application web multiplateforme, une API métier en plusieurs services (utilisateurs, ordres, dossiers KYC, bénéficiaires, messagerie, ordres conditionnels, prix) et une brique d'identité open source. L'ensemble était globalement bien tenu, et c'est ce qui rend le cas utile : les problèmes se trouvaient dans la logique métier et les accès persistants, là où les scanners automatiques ne regardent pas.

Cette étude de cas est anonymisée : ni plateforme, ni prestataire, ni composant identifiable, ni requête ou valeur réutilisable.

Périmètre et autorisation : dans quel cadre l'audit a-t-il eu lieu ?

L'audit était une mission autorisée, en boîte noire, avec deux comptes utilisateurs créés pour l'occasion, sans vérification d'identité, et des tests non destructifs. Aucune donnée de production réelle n'a été modifiée et les artefacts de test ont été nettoyés en fin de mission.

Le principe de test central s'appelle le test inter-comptes : le compte A crée un objet, le compte B tente de le lire, de le modifier ou de le supprimer. C'est la méthode la plus fiable pour trouver les défauts d'autorisation, et elle reproduit la situation d'un agent IA, qui agit avec les droits du compte qui l'a invoqué.

Règles appliquées : ordres de test annulés et statut vérifié, données fictives, prestataires tiers de vérification d'identité hors périmètre (aucun document soumis chez eux), et quelques traces fictives sans méthode de suppression signalées au client pour purge. Un ordre conditionnel laissé volontairement armé sur un compte non vérifié est consigné dans le rapport, avec la méthode pour en lire le résultat.

Ce que nous avons trouvé : quels constats, de quelle gravité ?

Aucun constat critique, mais trois constats structurants, dont deux dépendent d'un fait que le test ne pouvait pas observer. Le rapport l'indique : une sévérité conditionnelle vaut mieux qu'un faux critique.

Les trois constats qui comptent :

1. Clés d'API (moyen, élevé en contexte financier). Une clé se crée avec la seule session ouverte, sans mot de passe, sans second facteur, sans e-mail d'alerte. Elle n'expire jamais, elle continue de fonctionner après la déconnexion complète de la session, et une clé peut en créer d'autres.
2. Ordres à montants négatifs (moyen prouvé, critique si exécution). Le serveur accepte et stocke comme actifs des ordres conditionnels dont le montant et le prix sont négatifs. L'exécution par le moteur n'a pas pu être observée dans la fenêtre de test.
3. Dossiers de bénéficiaires effectifs (moyen+ prouvé, élevé si les identifiants circulent). Deux méthodes ne vérifient pas que l'identifiant fourni appartient au compte appelant. Elles permettent de lire les informations d'un tiers et de générer des sessions de vérification d'identité valides sur son dossier.

La chaîne d'attaque : comment un compte ordinaire devient-il une menace pour la plateforme ?

Il existe deux chaînes conceptuelles, l'une côté compte, l'autre côté moteur de trading.

Chaîne 1 : de l'accès temporaire à l'accès permanent.

1. L'attaquant obtient une session de la victime par un moyen classique (script malveillant injecté, vol de cookie, poste partagé). Trente secondes suffisent.
2. Avec cette session, il crée une clé d'API. Aucune ré-authentification, aucune alerte.
3. Il crée éventuellement plusieurs clés de secours, puisqu'une clé peut en créer d'autres.
4. La victime détecte l'incident, se déconnecte partout, change son mot de passe. Les clés restent valides : l'attaquant conserve un accès complet et silencieux aux soldes, au dossier KYC, aux bénéficiaires et à l'historique.

La survie à la déconnexion et la création de clés par une clé ont été prouvées. La survie au changement de mot de passe n'a pas été testée, car elle exigeait une session privilégiée, mais elle découle de l'architecture.

Chaîne 2 : du compte gratuit au moteur de trading.

1. L'attaquant ouvre un compte gratuit. Le service d'ordres conditionnels accepte même les comptes non vérifiés, contrairement au service d'achat direct.
2. Les messages d'erreur de validation décrivent le schéma exact attendu : champs, types, contraintes. Il reconstruit le format d'un ordre en quelques minutes.
3. Il soumet des ordres incohérents, que le serveur stocke comme actifs pour un an.
4. Si le moteur d'exécution traite un ordre négatif, le risque va de l'écriture comptable aberrante au blocage du traitement périodique pour tous les utilisateurs.

Aucun maillon n'est sophistiqué. Une session volée devient durable à cause d'un mécanisme de confort, et l'absence d'un contrôle trivial ouvre l'intégrité du moteur à n'importe quel compte.

Ce qui tenait : quels contrôles fonctionnaient bien ?

Beaucoup de défenses tenaient :

• Les tentatives de modification et de suppression sur les dossiers d'un autre compte ont toutes été bloquées, même si la réponse était parfois une erreur interne et non un refus propre.
• L'injection d'un identifiant utilisateur dans les requêtes était ignorée : l'identité vient de la session.
• Les tentatives de mass assignment (forcer un statut vérifié ou des groupes) étaient neutralisées.
• Les listes de messages, d'ordres et de bénéficiaires étaient isolées par session ; les pièces jointes renvoyaient un refus propre.
• Les jetons falsifiés, expirés ou sans signature étaient rejetés, le CORS ne reflétait pas l'origine, et l'énumération de comptes par la connexion échouait.
• Côté portefeuille non-custodial, la phrase de récupération reste dans le stockage sécurisé du système et la sauvegarde est chiffrée côté client.

Correctifs : que faut-il changer, et dans quel ordre ?

Le plan se classe par urgence et par effort :

• 24 à 48 heures : validation serveur du signe et de la cohérence des montants et prix, contrainte en base, purge des ordres incohérents ; contrôle de propriété sur les deux méthodes de dossiers, suppression de l'enregistrement par défaut renvoyé à tous, invalidation de l'ancienne session lors d'une régénération.
• Cette semaine : ré-authentification et second facteur pour créer une clé, invalidation des clés à la déconnexion globale et au changement de mot de passe, interdiction de créer une clé avec une clé, expiration, lecture seule par défaut, notification par e-mail ; refus uniformes ; création atomique du bénéficiaire et de l'ordre ; politique anti-usurpation d'e-mail en quarantaine puis en rejet.
• Ce mois-ci : en-têtes de sécurité, messages de validation génériques, politique de mot de passe et dérivation de clé renforcées pour la sauvegarde, masquage des écrans sensibles, retrait de l'ancienne application.

Ce que ça change pour un agent IA : que se passe-t-il quand un assistant agit sur un compte de trading ?

Un assistant IA qui agit sur un compte de trading ou de paiement avec le jeton de l'utilisateur hérite de toutes les lacunes d'autorisation de l'API. Le modèle ne sait pas qu'un identifiant appartient à quelqu'un d'autre, ni qu'un montant négatif est absurde.

Trois conséquences concrètes :

1. Les défauts d'autorisation deviennent des actions. Si une méthode accepte l'identifiant d'un tiers, une injection de prompt dans un message, un document ou une page web suffit à pousser l'agent à l'appeler. L'attaquant n'a plus besoin de voler un identifiant : il le fait fournir par le contexte. C'est le scénario décrit par la catégorie « Excessive Agency » de l'OWASP pour les applications LLM.
2. Les accès persistants survivent à la remédiation. Un agent qui peut créer une clé d'API, ou un outil qui expose cette méthode, offre à un attaquant exactement la chaîne 1 : l'incident semble clos après la déconnexion, alors qu'un accès parallèle existe. Les capacités de création d'accès doivent être exclues du périmètre de l'agent.
3. La validation doit vivre hors du modèle. Montant positif, plafond, liste d'adresses de destination connues, délai avant exécution : ces règles s'appliquent dans un contrôleur déterministe entre l'agent et l'API, et ne se négocient pas dans un prompt. Toute action de paiement ou d'ordre exige en plus une approbation humaine explicite, présentée avec les paramètres réels de l'action, pas avec le résumé du modèle.

C'est exactement le rôle d'une couche d'action placée entre ce que le modèle propose et ce que le système autorise. Notre guide sur la sécurité des agents IA détaille cette approche, et la page sur le red team d'agent IA explique comment nous la testons. Nous retrouvons le même schéma dans l'étude de cas du webhook n8n et dans l'étude de cas du paywall Supabase : une porte annexe, jamais testée comme une porte, qui contourne les protections de l'entrée principale.

Pour approfondir : l'article sur le BOLA et l'IDOR dans les API, celui sur le human-in-the-loop pour les actions d'agent et celui sur l'excessive agency.

Résultat : que retenir de cet audit ?

La plateforme n'avait aucune faille critique et une bonne isolation entre comptes, mais trois mécanismes de confort ou de laxisme métier (clés d'API durables, absence de contrôle de signe, identifiants non rattachés à un propriétaire) y créaient des chemins d'attaque réels. Leur correction demande quelques jours de développement ciblé.

Pour toute organisation qui prévoit de brancher un agent IA sur une API financière, la règle de départ est de tester d'abord l'API comme si l'agent était un utilisateur hostile : deux comptes, des identifiants croisés, des valeurs aberrantes, des accès persistants. Le Red Team Agent Express couvre ce périmètre en cinq jours pour 1 900 €.

Les autres études de cas

• Webhook n8n : comptes administrateur ouverts
• Paywall Supabase contourné en deux requêtes
• Application SaaS de rédaction IA
• Restaurant : back-office ouvert par un fichier oublié