Comment gérer une API Key Binance ? Configuration à permission minimale et revue périodique
Par défaut, une API Key Binance n'a que la permission de lecture ; il faut cocher explicitement pour activer le trading spot, le trading en contrats à terme ou le retrait. La meilleure pratique consiste à répartir plusieurs clés selon l'usage + à lier une liste blanche d'IP + à les faire tourner tous les 90 jours. Cet article documente notre configuration réelle de 5 API Key et les pièges rencontrés.
L'API Key Binance est un jeton d'accès destiné au trading algorithmique, à l'abonnement aux données de marché et aux plateformes de stratégie tierces. En vous connectant au site officiel de Binance → [Gestion des API], une clé créée n'a par défaut que la [permission de lecture] ; [Trading spot], [Trading en contrats à terme] et [Retrait] doivent être cochés séparément pour être activés. Cette fois, nous avons configuré 5 clés indépendantes pour différents usages, chacune avec le minimum de permissions + une IP liée, afin de limiter la perte maximale d'une fuite ponctuelle au seul périmètre de permission de cette clé.
La règle la plus importante : n'activez jamais la permission de retrait sur une API Key, sauf si votre programme a réellement besoin de retirer des fonds automatiquement. 99 % des programmes n'en ont pas besoin, mais si elle est activée et que la clé fuite, les fonds peuvent être vidés directement. Même si elle est activée, il faut absolument la combiner avec une liste blanche (voir Comment activer la liste blanche de retrait Binance ? Détails sur l'ajout et la période de refroidissement).
Ce que font les 5 permissions
Voici le tableau de toutes les options de permission d'une API Key Binance et la stratégie de configuration recommandée :
| Permission | Rôle | Risque | Recommandation |
|---|---|---|---|
| Enable Reading (lecture) | Consulter le marché, le solde, les ordres | Très faible | À cocher obligatoirement |
| Enable Spot & Margin Trading (trading spot et marge) | Passer et annuler des ordres | Moyen (risque de perte par manipulation d'ordres) | Selon le besoin |
| Enable Futures (trading en contrats à terme) | Ordres à terme, ajustement du levier | Moyen-élevé (le levier amplifie les pertes) | Selon le besoin |
| Enable Withdrawals (retrait) | Retrait on-chain vers une adresse donnée | Très élevé (vidage direct) | Presque jamais à cocher |
| Permits Universal Transfer (virement inter-comptes) | Virement entre les comptes spot / contrats à terme / financement | Faible | Selon le besoin |
La permission de lecture est présente par défaut, inutile de la cocher. Les permissions de trading spot et à terme se cochent selon l'usage de votre programme. La permission de retrait ne doit être cochée qu'en dernier recours, et doit obligatoirement être suivie d'une liaison d'adresse de retrait (cette étape se fait dans la liste blanche, pas dans les paramètres de l'API Key).
Étape 1 : créer une API Key
Le point d'entrée [Gestion des API] se trouve dans [Centre de compte] → [Gestion des API], même chemin sur l'app. Cliquez sur [Créer une API] → choisissez [System generated] ou [Self-generated] :
| Type | Différence | Cas d'usage recommandé |
|---|---|---|
| System generated (générée par le système) | Binance génère le secret, visible une seule fois | 99 % des cas |
| Self-generated (auto-signée) | Clé publique Ed25519/RSA, le secret n'est jamais transmis | Cas à haute exigence de sécurité |
Pour un usage courant, [System generated] suffit. Donnez un nom à la clé (30 caractères max, par exemple bot-spot-grid-arb) puis cliquez sur [Créer]. Le système demandera un code 2FA + une vérification email + un code SMS (si lié) — les trois codes doivent être validés pour générer la clé.
Une fois générée, l'API Key (clé publique, 64 caractères) et la Secret Key (clé privée, 64 caractères) s'affichent. La Secret Key n'est affichée qu'une seule fois — une fois la page fermée, elle disparaît définitivement. Copiez-la immédiatement dans un gestionnaire de mots de passe ou une note chiffrée ; si vous la perdez, il ne reste plus qu'à supprimer la clé et en recréer une nouvelle.
Étape 2 : cocher les permissions
Une clé nouvellement créée n'a par défaut que la permission de lecture. Pour activer les permissions de trading, cliquez sur [Edit restrictions] → cochez les permissions correspondantes → saisissez le code 2FA pour confirmer. Chaque modification de permission déclenche une nouvelle vérification 2FA + email.
Voici la configuration de nos 5 clés cette fois-ci :
| Nom de la clé | Usage | Permissions | Restriction IP |
|---|---|---|---|
bot-spot-grid |
Robot de grille spot | Lecture + trading spot | Limitée à 1 IP |
bot-futures-trend |
Stratégie de suivi de tendance en contrats à terme | Lecture + trading à terme | Limitée à 1 IP |
tax-export |
Outil d'export pour la déclaration fiscale | Lecture seule | Limitée à 2 IP |
dashboard-only |
Consultation de mon propre tableau de bord | Lecture seule | Non restreinte (utilisée uniquement sur le WiFi domestique) |
manual-transfer |
Outil de virement manuel inter-comptes | Lecture + virement inter-comptes | Limitée à 1 IP |
Aucune des 5 clés n'a la permission de retrait activée. Si l'une d'entre elles venait à fuiter un jour, la perte maximale serait limitée à une manipulation d'ordres par un adversaire (encore faut-il que cela corresponde à la permission spot/à terme de cette clé) — les fonds eux-mêmes ne peuvent pas être retirés.
Étape 3 : lier une liste blanche d'IP — l'étape clé
Sur la page [Edit restrictions], en bas se trouve [Restrict access to trusted IPs only]. Cliquez dessus pour saisir les adresses IP (plusieurs séparées par des virgules, 30 maximum).
Pourquoi lier une IP est indispensable :
- Même si l'API Key + le Secret fuitent, l'adresse IP du serveur de l'attaquant ne sera pas dans la liste blanche
- Le serveur de Binance rejettera toutes les requêtes provenant d'autres IP, en renvoyant une erreur -2015
- Cela ajoute une couche supplémentaire d'authentification « géographique »
Le prix à payer si l'IP n'est pas liée :
- Une clé sans restriction IP est automatiquement invalidée par Binance après 90 jours (règle en vigueur depuis 2024)
- Une clé avec IP liée n'expire pas automatiquement, elle peut être utilisée à long terme
Comment trouver l'IP de votre serveur :
- Robot auto-hébergé : exécutez
curl ifconfig.mesur cette machine pour voir l'IP de sortie - Fonction cloud ou PaaS : consultez l'IP de sortie fixe fournie par le prestataire (beaucoup de PaaS ont une IP de sortie non fixe, nécessitant une configuration NAT dédiée)
- Exécution à domicile : l'IP publique de votre connexion internet (une IP dynamique qui change chaque jour est très contraignante, non recommandé pour un usage domestique)
Si votre programme est déployé sur un environnement à IP dynamique (par exemple un réseau domestique, du travail mobile), ne pas lier d'IP entraîne l'expiration forcée à 90 jours, mais en lier une provoquera des échecs à chaque changement d'IP. Dans ce cas, il faut soit passer sur un VPS (IP fixe), soit adopter une solution de pénétration réseau interne.
Cette fois, sur nos 5 clés, 4 avaient une IP liée ; la restante [dashboard-only], du fait de son usage en lecture seule et de sa permission déjà minimale, ne nécessitait pas de liaison pour rester sûre.
Étape 4 : tester le fonctionnement de la clé
Une fois créée, testez avec curl :
curl -H "X-MBX-APIKEY: votre API Key" \
https://api.binance.com/api/v3/account?timestamp=1234567890&signature=xxx
Si les informations du compte sont retournées, la clé fonctionne normalement. En cas d'erreur :
| Code d'erreur | Signification | Traitement |
|---|---|---|
| -2014 | API Key invalide | Vérifiez que la clé est correctement copiée, sans espace |
| -2015 | IP hors liste blanche | Vérifiez l'IP de sortie actuelle, ajoutez-la à la liste blanche |
| -1022 | Erreur de signature | Vérifiez la Secret Key et l'algorithme de signature |
| -1021 | Horodatage hors fenêtre | L'horloge du serveur n'est pas synchronisée, resynchronisez |
| -2010 | Permission absente | Cette permission n'est pas cochée sur la clé, allez l'ajouter dans [Edit] |
| -4007 | Adresse de retrait hors liste blanche | Rencontré uniquement avec l'API de retrait, ajoutez à la liste blanche |
L'erreur la plus fréquente est -2015 (IP hors liste blanche), car beaucoup de gens ignorent leur véritable IP de sortie (par exemple en utilisant un VPN, Cloudflare, ou un réseau d'entreprise). Dans [Gestion des API] de l'application officielle Binance, on peut aussi voir la [Dernière IP d'accès], à comparer avec l'IP que vous pensiez être la bonne.
Étape 5 : revue périodique + rotation
Faites un bilan de santé de vos API Key tous les 90 jours :
1. Lister toutes les clés : La page principale de [Gestion des API] affiche la liste complète des clés, avec pour chacune la date de création, la dernière date d'accès, les permissions et les restrictions IP, tout en un coup d'œil.
2. Repérer les clés suspectes :
- Une clé dont vous ne savez plus pour quel programme elle servait → supprimez-la
- Une clé sans « dernier accès » depuis 30 jours → supprimez-la
- Une clé sans IP liée → ajoutez une IP ou supprimez-la
- Une permission dépassant le besoin réel → réduisez-la au minimum
3. Rotation active : Pour les clés importantes (celles touchant des actifs conséquents), il est conseillé de les recréer activement tous les 90 jours : supprimer l'ancienne → créer une nouvelle → la mettre à jour dans le programme → vérifier le fonctionnement → terminer. Ce processus interrompt brièvement le programme (1 à 5 minutes) ; choisissez une plage horaire à faible activité pour le faire.
4. Vérification avant suppression : La suppression d'une API Key prend effet immédiatement et est irréversible. Avant de supprimer, confirmez que :
- Cette clé n'est référencée dans aucun programme en cours d'exécution
- Cette clé n'est utilisée dans aucun cron job ni tâche planifiée
- Aucune trace résiduelle dans les fichiers
.envou de configuration d'un dépôt Git (ils devraient déjà être dans.gitignore, mais vérifiez quand même)
Réponse d'urgence en cas de fuite d'une API Key
Si vous découvrez qu'une clé a peut-être fuité (par exemple, poussée par erreur vers un dépôt Git public), agissez immédiatement :
- Première seconde : supprimez cette clé dans [Gestion des API]
- Deuxième seconde : vérifiez l'historique des transactions de cette clé des dernières 24 heures pour repérer des ordres suspects
- Troisième seconde : si la permission de retrait était activée, vérifiez s'il y a eu un retrait suspect (il devrait être bloqué par la liste blanche, mais vérifiez quand même)
- Quatrième seconde : changez le mot de passe du compte + réinitialisez la 2FA (même sans preuve que d'autres identifiants ont fuité, nettoyez tout par précaution)
- Ensuite : si déjà poussé sur Git, la simple suppression de la clé ne suffit pas ; il faut aussi effacer le secret de l'historique Git avec
git filter-branchou l'outil BFG, sinon quelqu'un pourrait le retrouver dans l'historique des commits
GitHub et GitLab proposent tous deux des services de scan automatique de secrets ; une fois qu'un Secret d'API Binance est poussé sur un dépôt public, Binance reçoit généralement une notification de la plateforme et invalide proactivement la clé sous quelques heures, mais ce n'est qu'un filet de sécurité, il ne faut pas s'y fier.
Les pièges des plateformes tierces utilisant une API Key
De nombreux outils tiers (plateformes de stratégie, outils fiscaux, gestionnaires de portefeuille) vous demandent de renseigner votre API Key. Le principe à suivre :
| Type de plateforme tierce | Permission à accorder | Signal d'alarme |
|---|---|---|
| Outil d'export pour la déclaration fiscale | Lecture seule | Demande d'ouvrir la permission de retrait → fuyez |
| Tableau de bord de suivi de portefeuille | Lecture seule | Demande d'ouvrir la permission de trading → réfléchissez bien |
| Plateforme de copy trading / signaux / stratégies | Lecture + trading spot/à terme | Demande d'ouvrir la permission de retrait → fuyez absolument |
| Outil de prêt avec levier / avance de fonds | Ne touchez pas à ce genre d'outil, évitez-le | Tout ce qui demande un retrait, fuyez |
Ligne rouge : si une plateforme tierce insiste pour que vous activiez la permission de retrait, il y a 99 % de chances qu'elle cherche à s'enfuir avec vos fonds. La déclaration fiscale, le suivi de portefeuille et le copy trading n'ont jamais besoin de la permission de retrait ; ils n'ont besoin que de la lecture, au maximum de la permission de trading.
Cette fois, nous avons accordé à une plateforme de copy trading en contrats à terme la permission [lecture + trading à terme] ; quand elle a demandé la permission de retrait, nous avons refusé, et elle l'a accepté — preuve que cette permission était bien optionnelle : s'ils l'exigeaient vraiment, ils s'en iraient.
Questions fréquentes
Q : Laquelle est la plus sensible, l'API Key ou la Secret Key ? R : La Secret Key est plus sensible. L'API Key n'est qu'un identifiant utilisateur communicable, tandis que la Secret Key est la clé de signature — sa fuite équivaut à un vol de toutes les permissions. Le Secret ne doit jamais être écrit dans un email, un chat ou une Issue.
Q : Comment conserver l'API Key et le Secret en sécurité ?
R : En local, utilisez un gestionnaire de mots de passe comme 1Password / Bitwarden / KeePass ; sur un serveur, utilisez des variables d'environnement + Docker secrets ou K8s Secret, sans jamais les coder en dur dans le code source. Assurez-vous que .env figure bien dans .gitignore du dépôt Git.
Q : Peut-on renommer une API Key après création sur Binance ? R : Oui. Dans [Gestion des API] → trouvez la clé → [Edit restrictions] permet de la renommer. Le renommage n'affecte ni la clé ni le secret, c'est juste une étiquette pour votre propre usage.
Q : Quel est le nombre maximum d'API Key ? R : 30 clés maximum par compte. En général, 5 à 10 suffisent pour bien répartir les usages ; les 30 sont conçues pour les nombreux sous-comptes et les équipes quantitatives.
Q : Y a-t-il une différence entre l'API d'un sous-compte (Sub-Account) et celle du compte principal ? R : Oui. L'API d'un sous-compte ne peut opérer que sur les actifs de ce sous-compte, pas sur le compte principal. Les sous-comptes sont aussi isolés entre eux. Ils conviennent particulièrement à l'isolement des stratégies et des risques, très utilisés par les équipes quantitatives.
Q : L'API Key a-t-elle une limite de fréquence d'appel ? R : Oui. Toutes les interfaces de Binance ont une limite de weight (poids) ; une interface simple pèse 1, une complexe peut peser 20. Chaque IP dispose d'un quota total de 1200 de weight par minute, au-delà duquel une erreur de limitation -1003 est renvoyée. Consulter un solde ou un ordre est léger, passer un ordre aussi ; consulter tous les chandeliers ou toutes les paires de trading épuise vite le quota.
Q : L'historique des transactions disparaît-il après suppression d'une API Key ? R : Non. L'historique des transactions et des ordres appartient au niveau du compte, indépendamment de la clé sous laquelle l'ordre a été passé. Supprimer une clé n'arrête que ce jeton d'accès, toutes les données du compte restent conservées.
Q : La liste blanche d'IP prend-elle en charge l'IPv6 ? R : Oui. La liste blanche IP de l'API Binance accepte à la fois les adresses IPv4 et IPv6, avec un format de saisie identique. Si votre serveur dispose d'une sortie v4 et v6, il est conseillé d'ajouter les deux.
Q : Que signifie l'expiration automatique à 90 jours de l'API ? R : Une API Key sans liste blanche d'IP liée expire automatiquement 90 jours après sa création et doit être recréée. Une clé avec IP liée n'expire pas automatiquement. Cette règle figure dans les annonces officielles de Binance, en vigueur depuis 2024, principalement destinée à nettoyer les clés anciennes et non maintenues.