Refus catégorique des clés API avec retrait activé : approfondissement technique

La plupart des plateformes de trading acceptent les clés API avec permission de retrait activée. Elles affichent une bannière d'avertissement jaune, vous demandent de taper « Je comprends », et stockent la clé de toute façon. Nous ne faisons pas cela. Si votre clé dispose d'une permission de retrait, nous la refusons lors de l'onboarding et ne la stockons jamais. Cet article explique pourquoi, comment, et ce que l'alternative vous coûte réellement.

Le modèle de menace en un paragraphe

Tout système qui détient une clé API avec retrait activé se trouve à une fuite d'identifiants près de vider les comptes des utilisateurs. La fuite n'a pas besoin d'être une violation de base de données — elle peut être un ordinateur portable d'employé compromis, une sauvegarde mal configurée, un side-channel dans une dépendance tierce, ou un dump de mémoire de processus échouant dans un journal non chiffré. Chacun de ces scénarios s'est produit chez des entreprises plus grandes que nous. La seule défense durable est : ne pas détenir les clés d'accès aux fonds de quelqu'un d'autre.

Comment fonctionne la détection

Au premier appel authentifié après que l'utilisateur colle une clé, nous effectuons un appel d'introspection de permission spécifique à l'exchange. La plupart des grands venues exposent soit :

• Un endpoint dédié « query API key info » qui retourne l'ensemble des permissions sous forme de champ structuré, soit
• Un endpoint account-info où l'étendue des permissions de la clé est incluse comme partie du payload de réponse.

Nous recherchons tout flag accordant le retrait, le transfert interne, le transfert de sous-compte sortant, ou le transfert universel sortant — les venues utilisent des noms différents pour la même chose. Si l'un de ces éléments est présent, nous supprimons le secret de la mémoire immédiatement, retournons une erreur structurée à l'UI, et n'écrivons jamais la clé dans notre base de données.

Pourquoi un refus catégorique au lieu d'un avertissement

Les avertissements sont contournés. Nous observons ces données depuis des années sur plusieurs produits. Le taux de base d'utilisateurs tapant « Je comprends » sans lire un seul mot au-dessus est quelque part au-delà de 80%. Un avertissement que 80% des utilisateurs ignorent n'est pas un contrôle de sécurité ; c'est un bouclier de responsabilité.

Le refus catégorique est l'inverse. Il place le friction au bon endroit : l'utilisateur retourne à l'exchange, crée une nouvelle clé avec permission de trading seulement, revient, et colle celle-ci. L'ensemble de la boucle coûte à l'utilisateur peut-être deux minutes. Cela coûte à l'attaquant — dans le pire scénario de fuite d'identifiants — le compte entier.

Ce que le schéma avertissement-et-stockage vous coûte réellement

Le pattern avertissement-et-stockage semble convivial jusqu'à ce que vous vous posiez la question : quel est le pire scénario ? Vous avez un employé hostile, une compromission de chaîne d'approvisionnement, un side-channel dans une dépendance transitive, un journal mal scoped, et la réponse est que les clés avec retrait activé sont exactement aussi sûres que la personne la plus faible et le code le plus faible qui les ont jamais manipulés.

Le refus catégorique inverse ce calcul. Même dans un pire cas de compromission complète de la base de données, l'attaquant repart avec des clés read+trade. Les clés trade-only peuvent causer des dégâts — elles peuvent bloquer les positions, générer des frais, liquider les positions ouvertes dans des paires illiquides — mais elles ne peuvent pas retirer. Les fonds restent sur l'exchange. Ce n'est pas zéro risque, mais c'est le risque que vous avez accepté quand vous avez connecté un agent de trading automatisé.

Ce que nous ne pouvons toujours pas défendre

Nous ne prétendons pas que le refus catégorique est une posture de sécurité complète. C'est un contrôle. L'ensemble complet est documenté sur notre page de sécurité : chiffrement d'enveloppe KMS avec clés de données par utilisateur, secrets déchiffrés qui vivent uniquement en mémoire de processus et uniquement pour la durée d'un appel API, journal d'audit hashé chaîné append-only, isolation cross-user testée en CI, et un programme de divulgation de vulnérabilités. Le refus catégorique de permission de retrait est juste la partie la plus visible de cette pile — et la plus facile à vérifier vous-même, parce que vous pouvez nous regarder refuser une clé avec retrait activé en temps réel lors de l'onboarding.