L'Approve (autorisation) de token est le mecanisme standard qui permet aux tokens ERC20 d'interagir avec des contrats intelligents, mais c'est aussi le plus grand vecteur d'attaque DeFi de 2024-2026. Cet article detaille le mecanisme Approve et les operations de revocation. Conclusion d'abord : chaque interaction DeFi peut laisser un residu d'Approve, ne jamais revoquer a long terme accumule un risque enorme, et auditer chaque mois avec Revoke.cash puis revoquer les autorisations inutiles est une habitude indispensable pour tout utilisateur DeFi. Pour votre compte principal comme secondaire, inscrivez-vous via le Site Officiel de Binance, installez l'Application Officielle Binance sur Android, et les utilisateurs iOS consulteront la Page de Telechargement pour basculer sur un Apple ID etranger.
Principes du mecanisme Approve
Le double mecanisme des tokens ERC20 :
Le standard ERC20 definit deux modes de transfert :
- transfer : l'utilisateur transfere lui-meme (vous envoyez des USDC a quelqu'un)
- transferFrom : le contrat transfere a votre place (un contrat intelligent preleve des USDC depuis votre compte)
transferFrom necessite d'abord un Approve :
Etape 1 : l'utilisateur appelle approve(spender, amount) sur le contrat USDC
- spender = adresse du contrat
- amount = montant autorise
Etape 2 : le contrat appelle transferFrom(user, recipient, amount)
- doit rester dans la limite de amount pour reussir
Exemple avec Uniswap :
Etape 1 : l'utilisateur Approve le Router Uniswap pour prelever des USDC (Approve unique de 1000 USDC)
Etape 2 : l'utilisateur lance un swap USDC vers ETH sur Uniswap
Etape 3 : le Router Uniswap appelle USDC.transferFrom pour prelever les USDC
Etape 4 : le Router Uniswap envoie a l'utilisateur le montant correspondant d'ETH
Approve est le mecanisme fondamental de toute interaction DeFi avec les tokens ERC20.
Q : Faut-il refaire un Approve a chaque interaction ?
Non. L'Approve est persistant :
- L'utilisateur Approve 1000 USDC pour Uniswap -> cette limite de 1000 USDC reste valable indefiniment
- L'utilisateur trade a repetition sur Uniswap, tant que le total ne depasse pas 1000 USDC, aucun nouvel Approve n'est necessaire
- L'Approve ne se termine que lorsque l'utilisateur le revoque activement ou l'epuise entierement
C'est la source du risque d'accumulation d'Approve : sans revocation a long terme, un grand nombre d'Approve historiques s'accumulent.
Les deux types d'Approve
Autorisation limitee (Limited Approval) :
- L'utilisateur autorise un montant precis (par exemple 1000 USDC)
- Le contrat ne peut prelever au maximum que 1000 USDC
- Une fois epuisee, il faut refaire un Approve
Autorisation illimitee (Unlimited Approval / MaxUint256) :
- L'utilisateur autorise un montant de 2^256-1 (pratiquement illimite)
- Le contrat peut prelever un montant illimite
- Plus jamais besoin de refaire un Approve
Pourquoi l'autorisation illimitee existe :
- Optimisation du gas : l'utilisateur n'Approve qu'une seule fois (economie de 50 a 200 dollars de gas)
- Experience utilisateur : eviter un Approve a chaque interaction
- Reglage par defaut des DApp : Uniswap, SushiSwap et d'autres appliquent l'Approve illimite par defaut
Les risques de l'autorisation illimitee :
- Apres le piratage d'un protocole, les tokens dans le wallet de l'utilisateur peuvent etre preleves sans limite
- Apres un Approve sur un contrat malveillant, tous les actifs restants peuvent etre transferes
- Difficile a detecter (l'utilisateur ne verifie pas activement)
Cas reel :
En decembre 2024, un utilisateur avait Approve un montant illimite d'USDC sur Uniswap des 2022. En decembre 2024, son wallet a recu un versement de 50 000 USDC, et 2 heures plus tard un contrat malveillant (un faux Router se faisant passer pour Uniswap V3) a appele transferFrom pour tout transferer. L'enquete a revele que le contrat de phishing avait exploite une faille dans un Approve historique de l'utilisateur.
Q : Faut-il choisir l'autorisation limitee ou illimitee ?
Camp de la securite (recommande) : Approve manuellement un montant precis a chaque interaction
- Avantage : securite elevee, perte unitaire maitrisee
- Inconvenient : consomme du gas a chaque fois (5 a 30 dollars)
Camp de la commodite : autorisation illimitee par defaut
- Avantage : economie de gas + un seul Approve pour un usage long terme
- Inconvenient : perte importante si le protocole est pirate
Strategie dominante :
- Tokens a montant eleve (>10 000 dollars) : autorisation limitee + revocation apres usage
- Tokens a montant faible (< 10 000 dollars) : autorisation illimitee + audit periodique
Les formes courantes d'attaques Approve
Forme 1 : attaque Approve via site de phishing
Un site de phishing imite l'interface reelle, l'utilisateur connecte son wallet puis signe une transaction Approve :
- Apparence : demande de "verifier le wallet" ou de "reclamer un airdrop"
- Realite : Approve d'USDC / USDT / WETH vers un contrat malveillant
- Suite : le contrat malveillant transfere tous les tokens autorises via transferFrom
Forme 2 : attaque par signature Permit
L'EIP-2612 introduit la fonction permit, qui permet d'autoriser par signature (hors chaine) :
- L'utilisateur signe un message Permit
- Le contrat utilise cette signature pour appeler permit puis transferFrom
- Les tokens du wallet de l'utilisateur sont preleves (sans Approve prealable)
Le danger des attaques Permit :
- La signature de l'utilisateur ne consomme pas de gas (hors chaine)
- L'interpretation du Permit dans l'interface de signature du wallet n'est pas intuitive
- L'utilisateur peut croire a tort qu'il s'agit d'une "signature inoffensive"
Forme 3 : piratage de protocole via un Approve historique
Piratage d'un protocole ayant un Approve historique :
- L'utilisateur a Approve un protocole DeFi il y a 2 ans
- Le protocole est pirate (fuite de cle privee / prise de controle du contrat)
- Le hacker appelle transferFrom via le protocole pour prelever tous les tokens autorises
Forme 4 : Token Drainer malveillant
Un site de phishing fait signer plusieurs Approve en une seule autorisation :
- Une seule signature regroupe plusieurs autorisations USDC / USDT / WETH
- L'utilisateur ne voit pas clairement le contenu precis des autorisations
- Une seule signature entraine l'autorisation de plusieurs tokens du wallet
Q : Une signature Permit est-elle plus dangereuse qu'un Approve ?
Oui, le Permit est bien plus dangereux :
| Dimension |
Approve |
Permit |
| Sur chaine |
Oui |
Non (signature seulement) |
| Consomme du gas |
Oui |
Non |
| Lisibilite dans le wallet |
Assez claire |
Peu intuitive |
| Mode de revocation |
Transaction Revoke sur chaine |
Impossible a revoquer (necessite de modifier le nonce du contrat) |
| Vigilance de l'utilisateur |
Elevee |
Faible |
Toute signature Permit doit etre verifiee attentivement : quel token, quel montant, quel destinataire.
Revoke : la revocation d'Approve en detail
Principaux outils de revocation :
Revoke.cash (le plus utilise, recommande) :
- Adresse : revoke.cash
- Chaines supportees : Ethereum + principales chaines EVM
- Operation : connecter le wallet -> consulter la liste des autorisations -> cliquer sur Revoke pour revoquer
Etherscan Token Approval :
- Adresse : etherscan.io/tokenapprovalchecker
- Ethereum mainnet uniquement
- Affiche le detail des autorisations
Solscan Approval (Solana) :
- Adresse : solscan.io/account-token-approval
- Solana uniquement
- Revoque les autorisations de tokens SPL
Etapes de revocation sur Revoke.cash :
1. Aller sur revoke.cash
2. Cliquer sur "Connect Wallet" (connecter MetaMask / Rabby)
3. Chargement automatique de toutes les autorisations (classees par token / protocole)
4. Parcourir la liste :
- Nom du token (USDC, USDT, WETH etc.)
- Beneficiaire de l'autorisation (adresse de contrat + nom du protocole connu)
- Montant autorise (valeur precise ou Unlimited)
- Niveau de risque (rouge = risque eleve, vert = protocole connu)
5. Cliquer sur "Revoke" pour revoquer les autorisations suspectes
6. Fenetre MetaMask : signer et payer le gas
7. Attendre la confirmation sur chaine (5 a 30 secondes)
Cout en gas d'une revocation :
| Chaine |
Gas d'une revocation unique |
| Ethereum mainnet |
5 a 30 dollars |
| Polygon |
< 0,01 dollar |
| Arbitrum / Optimism / Base |
0,1 a 1 dollar |
| BNB Chain |
0,05 a 0,30 dollar |
| Solana |
< 0,01 dollar |
Q : Faut-il payer du gas pour revoquer un Approve ?
Oui. Revoke est une transaction sur chaine, elle necessite du gas. Mais :
- Le gas d'Ethereum mainnet est relativement eleve (5 a 30 dollars / transaction)
- Le gas des L2 / autres chaines est extremement faible
Conseils d'optimisation :
- Revoquer quand le reseau est peu charge (nuit / week-end)
- Revoquer plusieurs autorisations en une seule fois (economie de temps groupee)
- Prioriser la revocation des autorisations a haut risque
Processus standard d'audit periodique des Approve
Frequence d'audit :
| Type d'utilisateur |
Frequence d'audit |
| Utilisateur DeFi actif (5+ interactions par semaine) |
Chaque mois |
| Utilisateur DeFi moyen (5 a 20 interactions par mois) |
Tous les 3 mois |
| Utilisateur DeFi peu frequent (< 5 interactions par mois) |
Tous les 6 mois |
Etapes d'audit :
Etape 1 : connecter le wallet a Revoke.cash
Etape 2 : filtrer les autorisations par categorie
Classement par niveau de risque :
- Risque eleve : autorisation Unlimited vers un contrat inconnu
- Risque moyen : autorisation Unlimited vers un protocole connu
- Risque faible : autorisation limitee vers un protocole connu
Etape 3 : revoquer les autorisations inutiles
Principes de revocation :
- Revoquer toutes les autorisations vers des contrats inconnus
- Revoquer les autorisations de protocoles non utilises (par exemple sans interaction depuis 1 an)
- Conserver les autorisations des protocoles principaux utilises (comme Uniswap, Aave etc.)
Etape 4 : conserver un enregistrement des autorisations necessaires
Enregistrer les autorisations conservees :
- Nom du protocole
- Adresse du contrat
- Montant autorise
- Usage
Etape 5 : verifier apres chaque audit
- Apres revocation, Revoke.cash ne doit plus afficher cette autorisation
- Verifier sur Etherscan que allowance(user, spender) = 0
Q : Comment savoir si un protocole est "connu" avant de revoquer ?
Methode de verification :
- Nom du protocole : le nom affiche par Revoke.cash (par exemple "Uniswap V3 Router")
- Adresse du contrat : rechercher sur Etherscan si le contrat est verifie + s'il s'agit d'un protocole reconnu
- Page protocole DefiLlama : consulter la TVL et la duree d'exploitation
- Documentation officielle : l'adresse de contrat publiee par l'equipe du projet
Tout contrat non identifiable + autorisation Unlimited = risque eleve, a revoquer immediatement.
Gestion des Approve sur differentes chaines
Ethereum mainnet + chaines compatibles EVM :
- Mecanisme identique : standard ERC20 + Approve / transferFrom
- Outil : Revoke.cash fonctionne universellement
- Cout en gas : Ethereum mainnet le plus cher, L2 / Polygon / BSC moins chers
Chaine Solana :
- Mecanisme different : les tokens SPL utilisent le modele "Token Account"
- Pas d'Approve / transferFrom : Solana utilise une "autorisation par signature"
- Outil de revocation : Solscan / Revoke integre a Phantom
Chaine Bitcoin :
- Pas de contrat intelligent : BTC n'a pas besoin d'Approve
- Reseaux de niveau 2 comme Lightning / Liquid : mecanismes differents
Familles Move (Sui / Aptos) :
- Mecanisme different : modele Object
- Necessite une logique de revocation differente
Q : Existe-t-il un risque d'Approve sur Solana ?
Oui. Le risque de "l'autorisation par signature" sur Solana est similaire :
- Un site de phishing fait signer une "Token Approval"
- Apres la signature, un contrat malveillant peut prelever les tokens
- La revocation se fait via Solscan ou directement dans le wallet
Phishing courant sur Solana :
- Pages de "Mint NFT gratuit"
- Reclamation d'un "Airdrop Solana"
- Faux sites imitant Jupiter / Raydium
Les principes de protection sont identiques a ceux d'Ethereum.
Meilleures pratiques d'optimisation des Approve
1. Utiliser un montant precis a chaque Approve
Configurer l'invite Approve de MetaMask :
- Lors de la signature d'un Approve dans MetaMask, remplacer l'Unlimited par defaut par un montant precis
- Exemple : pour trader 100 USDC, Approve 100 USDC (pas Unlimited)
2. Separer wallet principal et wallet secondaire
- Wallet principal (80 % des actifs) : ne jamais Approve aucun contrat
- Wallet secondaire (20 % des actifs) : interactions DeFi quotidiennes
- Wallet de test/airdrop (< 1 % des actifs) : tests a haut risque
3. Revoquer les anciennes autorisations de protocole
Audit mensuel :
- Revoquer les autorisations de protocoles non utilisees depuis 6 mois
- Revoquer les autorisations de protocoles abandonnes
- Revoquer les autorisations de domaines suspects (meme s'ils semblaient legitimes par le passe)
4. Se mefier des "signatures groupees"
- Plusieurs Approve dans une seule transaction
- L'utilisateur a du mal a les identifier
- Une seule signature, une perte totale
5. Utiliser des outils d'interpretation de signature
- Rabby Wallet : affiche l'effet reel de la signature
- Pocket Universe : payant, interpretation detaillee
- Wallet Guard : alerte sur les sites de phishing + les signatures
Q : Peut-on revoquer tous les Approve en une seule fois ?
Il n'existe pas de fonction "tout revoquer en un clic" :
- Chaque Approve est une transaction sur chaine independante
- Il faut revoquer un par un
- Plusieurs revocations peuvent etre regroupees dans un meme bloc (mais restent plusieurs transactions)
Certains outils proposent une "file d'attente" groupee :
- Revoke.cash : selectionner plusieurs autorisations -> signer une par une -> confirmer sur chaine une par une
- Chaque transaction consomme toujours du gas
Cas particulier : Approve NFT
Les NFT ont aussi un mecanisme Approve :
- setApprovalForAll : autorise un contrat a gerer toute une collection de NFT vous appartenant
- Exemple : pour mettre en vente un NFT sur OpenSea, il faut obligatoirement faire setApprovalForAll pour le contrat OpenSea
Les risques de l'Approve NFT :
- Nature Unlimited : setApprovalForAll est une "autorisation illimitee sur tous les NFT de la collection"
- Piratage de protocole : apres le piratage d'OpenSea / Blur etc., tous les NFT des utilisateurs peuvent etre preleves
- Scenario de phishing : imitation d'OpenSea / Blur pour faire signer un setApprovalForAll
Cas reel :
En mai 2024, un utilisateur a signe un setApprovalForAll sur un faux site imitant OpenSea, autorisant un contrat malveillant a gerer son BAYC NFT. Ses BAYC ont ete immediatement transferes vers l'adresse de l'attaquant, pour une perte d'environ 120 000 dollars.
Revocation de l'Approve NFT :
- Supporte par Revoke.cash
- Supporte par Etherscan Token Approval Checker
- Operation similaire a la revocation d'un Approve ERC20
Q : Faut-il obligatoirement autoriser pour vendre un NFT sur OpenSea / Blur ?
Oui. Les principales marketplaces NFT exigent une autorisation pour mettre en vente :
- OpenSea : setApprovalForAll pour le contrat OpenSea
- Blur : setApprovalForAll pour le contrat Blur
- Magic Eden : setApprovalForAll pour le contrat Magic Eden
Bonne pratique de securite :
- Revoquer immediatement le setApprovalForAll apres chaque vente de NFT
- Refaire l'autorisation lors de la mise en vente suivante
- Contraignant mais securise
FAQ courantes
Q : Combien de gas minimum consomme un Approve ?
Gas standard d'un Approve sur Ethereum mainnet :
- Approve de base : environ 46 000 gas
- A un Gas Price de 30 Gwei : environ 5 dollars
Sur L2 / Polygon / BSC, un Approve coute generalement moins de 1 dollar.
Q : Un Approve revoque peut-il etre reactive ?
Non, pas directement. Apres revocation, c'est comme si l'autorisation n'avait jamais existe, un nouvel Approve est necessaire :
- Nouvelle signature + transaction sur chaine + paiement du gas
Q : Tous les tokens ERC20 necessitent-ils un Approve ?
Oui. Tous les tokens standard ERC20 suivent le mecanisme Approve :
- Les stablecoins comme USDC / USDT / WETH / DAI
- Les tokens de gouvernance comme UNI / LINK / AAVE
- Tout token de projet
Exceptions :
- ETH (monnaie native d'Ethereum) : ne necessite pas d'Approve (transfer direct)
- BTC : ne necessite pas d'Approve (pas de contrat intelligent)
- Solana SPL : mecanisme different ("autorisation par signature")
Q : Le token reste-t-il bloque apres un Approve ?
Non. L'Approve ne bloque pas le token :
- L'Approve "permet" seulement au contrat de prelever
- Le token reste dans le wallet de l'utilisateur, utilisable normalement
- L'utilisateur peut transferer le token a tout moment (meme avec un Approve actif)
L'Approve fonctionne comme une "limite de carte de credit" : vous accordez un plafond au commercant, mais l'argent reste sur votre compte bancaire.
Q : Comment revoquer une signature Permit ?
Une signature Permit ne peut pas etre "revoquee" directement, mais il existe des methodes indirectes :
-
Modifier le nonce du contrat : appeler incrementNonce du contrat pour invalider le Permit
-
Ne plus utiliser le wallet : le Permit a une date d'expiration, il devient automatiquement invalide apres
-
Creer un nouveau wallet : transferer completement les actifs vers un nouveau wallet
La cle de la securite Permit reside dans la prevention : verifier attentivement chaque signature Permit avant de signer.
Q : Le risque Approve est-il identique entre USDT et USDC ?
Globalement similaire, mais avec des differences de detail :
- USDT : necessite d'abord approve(spender, 0) avant approve(spender, X) (une etape non requise par le standard ERC20 classique)
- USDC : ERC20 standard + support Permit (EIP-2612)
- DAI : les premieres versions supportaient Permit (implementation particuliere)
Q : Peut-on consulter tout l'historique des Approve passes d'un wallet ?
Oui :
- Etherscan : page de l'adresse -> "Token Txns" -> filtrer par Approve
- Revoke.cash : affiche les autorisations actives actuelles (n'affiche pas les autorisations deja revoquees)
- DeBank : profil de l'adresse + historique des autorisations
Q : La revocation d'un Approve prend-elle effet immediatement ?
Oui. Une fois la transaction Revoke confirmee sur chaine, l'effet est immediat :
- allowance(user, spender) passe immediatement a 0 sur chaine
- Le contrat ne peut plus appeler transferFrom
- Synchronisation sur l'ensemble du reseau (5 a 30 secondes)
Q : Peut-on revoquer les autorisations de plusieurs wallets en une fois ?
Non. Chaque wallet est independant :
- Chaque wallet doit se connecter separement a Revoke.cash
- Audit independant de la liste des autorisations
- Revocation independante
Utilisateurs multi-wallets : auditer chaque wallet separement chaque mois.
Sources des donnees
- Standard du protocole ERC20 (EIP-20)
- Standard EIP-2612 Permit
- Documentation de l'outil Revoke.cash
- Recueil de cas de phishing Approve par SlowMist
- Analyses d'incidents on-chain par Chainalysis
Avertissement sur les risques : cet article est une synthese independante par un tiers et ne constitue pas un conseil en investissement. L'Approve est un vecteur d'attaque DeFi majeur, l'audit periodique et la revocation sont des pratiques de securite de base. Toutes les donnees datent d'avril 2026.