Permissions de tokens : vérifier et révoquer en DeFi

En DeFi, un wallet peut détenir ses cryptomonnaies sans les confier à une plateforme. Cette autonomie a toutefois une contrepartie : chaque interaction avec un protocole demande de comprendre ce que l’on valide. Parmi les risques les plus mal compris figurent les permissions de tokens, aussi appelées approvals, allowances ou autorisations de dépense.

Une approval n’envoie pas vos tokens immédiatement. Elle permet en revanche à une adresse, souvent celle d’un smart contract, de les déplacer ultérieurement selon une limite fixée. Si vous avez donné une autorisation illimitée à un contrat malveillant, à un faux site ou à un protocole ensuite compromis, cette permission peut être exploitée pour transférer les tokens concernés hors de votre wallet.

Ce guide explique comment lire une approval ERC-20, distinguer une transaction d’une signature, contrôler ses autorisations sur Ethereum et les réseaux compatibles EVM, puis révoquer uniquement ce qui doit l’être. L’objectif n’est pas de cliquer sur « revoke » partout : il s’agit de réduire les risques sans multiplier les frais inutilement.

Pourquoi une approval peut vider des tokens après une simple signature

La plupart des tokens utilisés en DeFi suivent le standard ERC-20. Ce standard prévoit notamment deux fonctions essentielles :

approve : le détenteur autorise une autre adresse à dépenser un montant donné de tokens ;
transferFrom : l’adresse autorisée, ou spender, utilise cette autorisation pour transférer les tokens.

Concrètement, avant de déposer des USDC dans un protocole de prêt ou d’échanger des DAI sur un exchange décentralisé, l’interface vous demande souvent d’autoriser son contrat à accéder à ces tokens. Le contrat ne reçoit pas vos actifs au moment de l’approbation. Il reçoit le droit d’exécuter un transferFrom, dans la limite accordée.

Une autorisation se résume donc à trois éléments :

le token concerné, par exemple USDC ou WETH ;
le spender, c’est-à-dire l’adresse du contrat ou du wallet autorisé ;
le montant maximal que ce spender peut déplacer.

Le problème apparaît lorsqu’un utilisateur valide une autorisation très large, parfois appelée « unlimited approval ». Techniquement, les interfaces utilisent fréquemment la valeur maximale d’un entier non signé sur 256 bits, souvent affichée comme un montant énorme ou comme « unlimited ». Cette pratique évite de demander une nouvelle approval à chaque opération, mais elle laisse une permission active tant qu’elle n’est pas consommée, modifiée ou annulée.

Un scam DeFi classique repose sur un faux site qui imite l’interface d’un protocole connu. Il peut proposer un airdrop, une opportunité de staking ou la récupération de fonds. Si vous connectez votre wallet et validez une approval au profit du contrat indiqué par le site frauduleux, celui-ci peut ensuite appeler transferFrom pour les tokens visés.

Une approval ne donne pas accès à votre phrase de récupération et ne permet pas de déplacer tous les actifs par magie. Elle expose les tokens précis autorisés, auprès du spender précis, jusqu’au montant précis de l’autorisation.

Cette nuance est importante. Une approval ERC-20 sur USDC n’autorise pas automatiquement le transfert de votre ETH natif, de votre BTC ou de tous vos NFT. Mais un wallet peut contenir plusieurs tokens ; une succession de permissions trop larges peut donc représenter une exposition significative.

Le danger augmente lorsque le contrat approuvé est malveillant, quand son code comporte une faille, ou lorsqu’un protocole légitime a été compromis. Même un contrat connu mérite donc d’être vérifié avant toute validation, notamment si l’adresse affichée par votre wallet ne correspond pas à celle documentée par le protocole.

Transaction, signature et demande de connexion : ne pas tout confondre

Les pop-ups de wallet se ressemblent parfois, mais ils n’ont pas les mêmes conséquences. Avant de confirmer une demande dans MetaMask, Rabby ou un autre wallet EVM, commencez par identifier sa nature.

La connexion au site

Le bouton « Connect wallet » demande généralement l’accès à votre adresse publique. Cela permet au site d’afficher vos soldes et de préparer des transactions. Connecter un wallet ne donne pas au site le droit de déplacer vos tokens. Néanmoins, un site auquel vous êtes connecté connaît votre adresse et peut vous présenter des demandes de signature ou de transaction trompeuses.

La transaction on-chain

Une transaction est diffusée sur le réseau, enregistrée dans la blockchain et coûte du gas en ETH sur Ethereum ou dans le token natif du réseau concerné. Une fonction ERC-20 approve classique est une transaction. Votre wallet doit normalement montrer le contrat appelé, les frais estimés et une demande de confirmation.

Sur un explorateur comme Etherscan, une approval apparaît dans l’historique on-chain. La transaction modifie l’état du contrat du token : l’allowance associée à votre adresse et au spender évolue.

La signature hors chaîne

Une signature peut ne pas entraîner de frais immédiats ni créer de transaction visible à l’instant où vous cliquez. Elle prouve que votre wallet a validé un message. Cela ne signifie pas qu’elle est inoffensive.

Dans un usage bénin, une signature sert par exemple à vous connecter à une application via Sign-In with Ethereum. Mais les protocoles peuvent aussi employer des signatures structurées, souvent conformes à EIP-712, pour obtenir une permission exploitable par la suite.

Une signature peut notamment contenir :

l’adresse d’un token ;
un montant ;
un spender ou destinataire ;
une date d’expiration ;
un nonce, utilisé pour empêcher la réutilisation normale d’un même message.

Ne vous fiez donc pas à la seule absence de frais. « Gasless » ne veut pas dire « sans engagement ». Si votre wallet affiche un message illisible, une signature brute en hexadécimal, ou une demande qui ne correspond pas à l’action attendue, annulez-la.

ERC-20, Permit et Permit2 : ce que vous autorisez réellement

Les systèmes de permission ne sont pas tous identiques. Les comprendre évite de traiter une signature comme une simple formalité.

L’approval ERC-20 classique

Avec une approval classique, vous signez une transaction approve(spender, amount). Elle est enregistrée on-chain. Pour l’annuler, vous envoyez une autre transaction en fixant le montant à zéro.

Exemple : vous souhaitez échanger 500 USDC sur Uniswap. L’interface peut vous proposer d’autoriser le routeur Uniswap à utiliser 500 USDC, ou une somme plus élevée. Si vous autorisez 500 USDC et n’en échangez que 300, une allowance de 200 USDC reste généralement disponible.

Une approval limitée au besoin immédiat réduit l’exposition, mais elle implique davantage de transactions à l’avenir. Il n’existe pas de réglage universel : le bon niveau dépend du montant, de votre fréquence d’utilisation et de votre confiance dans le contrat.

Permit : une approval fondée sur une signature

Le standard EIP-2612 définit une fonction permit pour certains tokens ERC-20. Au lieu d’envoyer vous-même une transaction approve, vous signez un message. Une autre personne ou un contrat peut ensuite soumettre cette signature au réseau et payer le gas pour exécuter le permit.

Le résultat est fonctionnellement proche d’une approval : le spender reçoit une allowance sur le token. La différence est que l’utilisateur peut n’avoir signé qu’un message hors chaîne au départ. Selon l’application, le permit peut être soumis séparément ou intégré à une opération plus large.

Un permit légitime peut améliorer l’expérience utilisateur. Il ne faut pas le considérer comme suspect par principe. En revanche, vous devez vérifier les mêmes informations que pour une approval classique : quel token, quel spender, quel montant et quelle échéance.

Permit2 : une couche d’autorisation largement utilisée

Permit2, développé par Uniswap Labs, est un ensemble de contrats conçu pour normaliser certains mécanismes de permissions et de transferts. Il est utilisé par différentes applications et agrégateurs, mais sa présence ne constitue pas à elle seule une garantie de sécurité : il faut toujours contrôler le site, le contrat et le contenu de la demande.

Dans une configuration courante, l’utilisateur accorde d’abord au contrat Permit2 une approval ERC-20. Il peut ensuite signer des permissions plus précises à destination d’applications qui s’appuient sur ce système. Permit2 introduit notamment des notions de montants, de délais d’expiration et de nonces.

Le point pratique est simple : si vous avez approuvé Permit2 pour un token, cette approval apparaît comme une permission ERC-20 dont le spender est le contrat Permit2. Les autorisations internes ou les signatures associées peuvent ensuite nécessiter une vérification complémentaire dans les outils compatibles. Ne supposez pas qu’une révocation d’un ancien routeur DeFi annule automatiquement une permission donnée à Permit2.

Enfin, les NFT peuvent utiliser des mécanismes distincts, tels que setApprovalForAll pour les standards ERC-721 et ERC-1155. Une autorisation « for all » permet à un opérateur de gérer plusieurs NFT de la collection concernée. Même si cet article se concentre sur les ERC-20, ces permissions doivent aussi être contrôlées si vous utilisez des marketplaces NFT.

Les signaux d’alerte avant de valider une approval ou une signature

Un drainer ne dépend pas forcément d’une faille technique sophistiquée. Il exploite souvent la précipitation : une publicité sponsorisée, un faux lien Discord, une réponse sur X, un nom de domaine presque identique ou une interface copiée.

Voici les signaux qui justifient un arrêt immédiat :

un airdrop non sollicité qui exige de connecter le wallet ou de signer avant toute vérification ;
une URL proche du site officiel, avec une lettre, un tiret ou une extension différente ;
une promesse de rendement garanti, de remboursement urgent ou de récupération de fonds ;
une signature qui ne décrit pas clairement le protocole, le token et l’action attendue ;
une approval illimitée demandée pour une action ponctuelle ou pour un token que vous ne vouliez pas utiliser ;
un spender présenté sous une adresse brute sans que vous puissiez la rapprocher de la documentation officielle ;
un site qui vous pousse à désactiver les alertes de votre wallet ou à confirmer rapidement.

Les adresses blockchain sont longues et difficiles à lire. Ne les vérifiez pas seulement caractère par caractère depuis une fenêtre de wallet : partez du site officiel du protocole, de sa documentation ou de ses canaux reconnus, puis comparez l’adresse du contrat. Les liens sponsorisés dans les moteurs de recherche et les liens reçus en message privé ne sont pas une source de confiance suffisante.

Pour limiter les conséquences d’une erreur, il est utile de séparer les usages : un wallet principal ou hardware wallet pour la conservation, et un wallet avec un montant limité pour les tests, les mint, les nouveaux DEX et les campagnes airdrop. Cette séparation ne rend pas une signature risquée sûre, mais elle limite le montant potentiellement exposé.

Vérifier ses autorisations sur Ethereum et les réseaux EVM

Un audit de permissions consiste à recenser les couples token / spender encore actifs, puis à déterminer s’ils sont justifiés. Il faut le faire réseau par réseau : une allowance sur Ethereum n’est pas la même que sur Arbitrum, Base, Optimism, Polygon ou BNB Chain.

Utiliser les explorateurs de blocs

Etherscan propose un outil dédié aux approbations de tokens à l’adresse Token Approval Checker. Après connexion via votre wallet, il permet de consulter les approvals associées à une adresse sur Ethereum. Les autres explorateurs de la famille Etherscan proposent des outils comparables sur plusieurs réseaux compatibles EVM.

L’avantage d’un explorateur est de travailler avec les données on-chain. Il reste essentiel de vérifier l’URL avant de connecter le wallet : tapez vous-même l’adresse du site ou utilisez un favori vérifié.

Utiliser un outil spécialisé

Revoke.cash est un outil spécialisé dans la consultation et la révocation des approvals sur plusieurs réseaux EVM. Il permet d’identifier les spenders, les montants autorisés et, selon les cas, certaines approbations NFT ou permissions liées à Permit2.

Quel que soit l’outil choisi, adoptez la même procédure :

sélectionnez le bon réseau ;
connectez le wallet ou consultez d’abord son adresse publiquement si cette option est disponible ;
repérez les tokens à forte valeur et les allowances élevées ou illimitées ;
identifiez le spender et l’usage auquel il correspond ;
ne révoquez qu’après avoir vérifié que l’autorisation est obsolète, inconnue ou inutile.

Une adresse de contrat connue n’est pas automatiquement un problème. Par exemple, un protocole que vous utilisez encore régulièrement peut avoir besoin de son allowance pour éviter une nouvelle approval lors d’une prochaine opération. À l’inverse, une permission ancienne associée à un site que vous ne reconnaissez pas mérite une attention immédiate.

Consultez également l’historique récent de votre adresse dans l’explorateur. Une transaction transferFrom inconnue, un nouveau spender ou une approbation créée juste après l’interaction avec un site douteux sont des éléments à investiguer.

Révoquer au bon moment et éviter les frais inutiles

Révoquer signifie généralement remplacer une allowance existante par une allowance de zéro. Cette modification est une transaction on-chain, donc elle requiert du gas sur le réseau concerné.

Vous n’avez pas besoin de révoquer systématiquement chaque permission après chaque swap. Une approche plus rationnelle consiste à prioriser :

les approvals données à un site ou à un contrat que vous ne reconnaissez pas ;
les approvals illimitées sur des stablecoins ou des tokens à valeur importante ;
les permissions d’applications que vous n’utilisez plus ;
les autorisations créées dans le cadre d’un airdrop, d’un mint ou d’un test ;
les permissions liées à une interaction que vous jugez désormais suspecte.

Si une approval est inconnue et que le token reste dans le wallet, la révocation rapide est généralement préférable à l’attente. Si des transferts non autorisés ont déjà eu lieu, révoquer l’allowance ne restaure pas les fonds transférés. Il faut alors sécuriser ce qui reste : supprimer les permissions risquées, arrêter d’utiliser le wallet compromis pour les nouveaux usages, et envisager de transférer les actifs restants vers une nouvelle adresse dont la seed phrase n’a jamais été exposée.

La révocation doit être réalisée sur le même réseau que l’approval. Une permission USDC sur Arbitrum ne peut pas être annulée depuis Ethereum. Vérifiez donc le réseau affiché dans votre wallet avant de signer, ainsi que le token natif nécessaire au paiement du gas.

Modifier une approval de « illimitée » à un montant plus petit peut être utile lorsque vous continuez à utiliser l’application. Toutefois, certains tokens imposent des comportements particuliers lors de la modification d’une allowance non nulle. Dans le doute, passer d’abord par zéro, puis définir une nouvelle limite si nécessaire, est souvent la voie la plus compatible, au prix potentiel d’une transaction supplémentaire.

Ne payez pas de frais pour révoquer des permissions fictives. Des sites frauduleux peuvent afficher de faux avertissements ou vous proposer une « validation de sécurité » payante. Avant toute action, retrouvez l’allowance dans un explorateur reconnu ou dans un outil tel que Revoke.cash, puis vérifiez le contrat réellement concerné.

Mettre en place une routine de sécurité réaliste

La meilleure protection n’est pas de tout révoquer dans l’urgence, mais de réduire le nombre de décisions prises sans contrôle. Une routine simple suffit pour la plupart des utilisateurs DeFi.

Avant une première interaction : accédez au protocole depuis une source officielle, vérifiez le réseau et commencez avec une somme limitée.
Au moment de signer : distinguez connexion, transaction et signature ; vérifiez token, spender, montant et expiration lorsque ces données sont affichées.
Après un test ou un airdrop : contrôlez les permissions créées, en particulier si une approval illimitée a été demandée.
À intervalles réguliers : auditez les autorisations de vos wallets actifs sur chaque réseau utilisé.
Pour les montants importants : évitez de connecter le wallet de conservation à des applications inconnues et utilisez un wallet dédié aux interactions.

Les mécanismes d’approval existent parce qu’ils rendent les smart contracts utilisables : un DEX, un protocole de prêt ou un outil de paiement ne peut pas échanger ou déposer vos ERC-20 sans une forme d’autorisation. Le bon réflexe n’est donc pas de fuir toute permission, mais de traiter chaque demande comme un mandat précis : qui peut agir, sur quel actif, jusqu’à quel montant et pendant combien de temps ?

Conclusion : des permissions limitées, des décisions plus sûres

Les approvals ERC-20, les permits et Permit2 sont des outils normaux de la DeFi, mais ils deviennent dangereux lorsqu’ils sont validés aveuglément. Une transaction d’approbation peut rester active longtemps ; une signature peut avoir des effets on-chain différés ; un faux site peut exploiter la confusion entre les deux.

Gardez une approche pratique : vérifiez l’URL, l’adresse du spender, le token et le montant ; privilégiez les limites adaptées à l’usage ; auditez les permissions après des interactions inhabituelles ; révoquez les accès obsolètes ou inconnus. Avant votre prochaine opération DeFi, prenez quelques minutes pour consulter les autorisations de votre wallet : c’est souvent l’un des contrôles de sécurité les plus utiles et les plus accessibles.