Pourquoi un portefeuille peut être vidé « sans signature »
Objectif de ce guide : expliquer comment fonctionnent les autorisations
(l'approbation est l'acte d'accorder des droits, allowance est le plafond de dépenses enregistré),
décomposer l'essentiel
EVM est un groupe de réseaux blockchain compatibles qui utilisent les mêmes règles d'exécution de contrats intelligents,
où la gestion des jetons et du NFT est construite autour d'un système d'autorisations.
Dans ces réseaux approve, allowance et
La principale vulnérabilité ici est l’attente selon laquelle chaque dépense nécessitera une signature distincte. Dans une interface de portefeuille, la signature ressemble à une étape ordinaire (« autoriser », « connecter », « confirmer pour l'échange »), donc l'utilisateur confirme non pas un transfert, mais un octroi de droits qui est stocké dans le contrat et utilisé ultérieurement sans autre fenêtre de confirmation.
Un allowance inutile
(une limite inscrite dans le contrat qui définit le nombre de jetons pouvant être dépensés)
pour un stablecoin ou un actif
Si vous évaluez le risque DeFi de manière plus large que les approbations, ajoutez des surfaces d'attaque distinctes à votre liste de contrôle : dApp frontends, ponts, MEV, clés et erreurs opérationnelles. Guide de sécurité DeFi : carte des menaces et liste de contrôle .
Le phishing par approbation utilise les autorisations accordées via approve/permit.
(création ou modification d'un allowance)
ou
Une signature approve/permit ou
Qu’est-ce que le phishing d’approbation et pourquoi son « honnêteté » est malhonnête
Termes clés dans cette section :
-
Dépensier est l'adresse du contrat intelligent autorisée à dépenser les jetons ERC-20 du propriétaire
au sein d'un allowance via
transferFrom . -
Opérateur est une adresse qui a reçu le droit de transférer le NFTs du propriétaire via
setApprovalForAll , sans limite de nombre de jetons de collecte. - Allocation est une valeur dans un contrat ERC-20 qui définit le nombre maximum de jetons le spender peut dépenser.
- Revoke est une transaction qui réinitialise un allowance ou désactive un operator, mettre fin au droit de dépenser ou de transférer des actifs.
Le phishing d'approbation utilise des mécanismes d'autorisation normaux : l'octroi de droits semble légitime, n'entraîne pas de perte immédiate de fonds et n'est donc souvent pas perçu comme un risque au moment de la signature.
Phishing d'approbation est une attaque dans laquelle un utilisateur est persuadé d'accorder un autorisation (approbation/allowance) pour gérer les jetons ou NFTs, et ce droit est ensuite utilisé pour retirer des actifs. L'action dangereuse est déguisée en une étape d'interface familière : « confirmer pour l'échange », « autoriser la monnaie », « signer pour la réclamation », « accorder l'accès pour le dépôt ».
Contrairement au vol de clé, l’attaquant n’a pas besoin de la clé privée ni d’un transfert direct de fonds. Il suffit à l'utilisateur de une fois accorder à une adresse spécifique le droit de dépenser des actifs : un spender pour les jetons ERC-20 ou un operator pour NFTs. Après cela, le retrait est effectué sans nouvelles fenêtres de portefeuille et sans confirmations répétées de la part du propriétaire.
Au niveau de la blockchain, les transactions semblent valides : l'utilisateur a réellement modifié l'état du contrat et accordé des droits sur une adresse spécifique. C'est pourquoi le portefeuille n'est pas formellement « piraté » : les actifs sortent via des autorisations précédemment accordées, et non via un contournement de la signature.
Approve généralement ne transfère pas fonds immédiatement. Il enregistre une limite allowance dans le contrat de jeton, après quoi le spender peut appeler
Même si la balance n’a pas changé, la signature est souvent perçue comme sûre. Avec approbation illimitée ou setApprovalForAll, un attaquant peut retirer les actifs actuels et tout dépôt futur jusqu'à ce que le allowance soit réinitialisé ou que le statut du operator soit désactivé.
En termes simples : approve n'est pas un transfert, mais un octroi de droits de dépense à une adresse précise. Le phishing par approbation signifie que l'utilisateur est amené à accorder ce droit à une adresse contrôlée par un attaquant alors qu'il est présenté comme une étape normale d'échange, de création ou de réclamation.
Le phishing par approbation fonctionne grâce à des autorisations valides. Le danger apparaît après la signature, lorsqu’un droit de dépense actif est utilisé sans la participation du propriétaire.
Les autorisations dans EVM sont des enregistrements de droits dans des contrats, et non des actions ponctuelles ; c'est pourquoi approve peut rester actif pendant des mois et être utilisé sans signature répétée.
Comment fonctionnent les autorisations dans EVM : allowance, spender et « approve infini »
Une autorisation EVM est un enregistrement d'état dans un jeton ou un contrat NFT qui connecte votre adresse à une adresse spender/operator spécifique. Cet enregistrement définit qui peut dépenser des jetons via
- ERC-20 : approve → allowance → transferFrom
- L'utilisateur appelle approve(spender, montant) et spécifie l'adresse spender.
- Le contrat de jeton stocke le allowance limite — le nombre maximum de jetons que le spender peut dépenser.
- Le spender appelle transferFrom et dépense des jetons sans nouvelles signatures jusqu'à ce que le allowance devienne 0 ou soit épuisé.
- Le contrat vérifie allowance lors
transferFrom ; il ne demande pas la signature du propriétaire pour chaque dépense.
- L'allocation est liée au propriétaire → spender → jeton
- L'autorisation existe uniquement pour un jeton spécifique et un spender spécifique.
- Un approve pour USDT n'accorde pas l'accès à l'USDC et ne s'étend pas à d'autres contrats.
- Chaque nouveau jeton ou nouveau spender nécessite un approve distinct.
- L'approbation illimitée est la valeur maximale de allowance
- Avec approve illimité, le allowance stocke la valeur numérique maximale.
- Le spender reçoit le droit de dépenser les jetons de ce contrat dans la limite de cette valeur, y compris les futurs dépôts à l'adresse.
- L'autorisation reste active jusqu'à une transaction revoke, même si le service n'est plus utilisé.
- NFT : setApprovalForAll est le statut operator sans limite
- setApprovalForAll(operator, vrai) active le statut operator pour l’ensemble de la collection NFT du propriétaire.
- Il ne s'agit pas d'une limite en quantité ou en valeur : le droit demeure jusqu'à setApprovalForAll(operator, faux) est envoyé.
- Si le operator est compromis, le NFTs peut être retiré sans confirmation du nouveau propriétaire.
Le approve illimité pour le ERC-20 augmente le montant maximum pouvant être dépensé via
Les autorisations EVM sont des enregistrements de droits de longue durée dans les contrats. Un approve peut fonctionner pendant des mois, augmente de manière illimitée la limite de dépenses disponible et
Une signature permit (par exemple EIP-2612) donne à une application le droit de définir allowance via un message signé ; l'application utilise ensuite cette signature dans une transaction qui accorde des droits et exécute l'action en un seul appel.
Permis, Permit2 et signatures de messages : comment les autorisations sont accordées sans approve distinct et pourquoi les attaquants l'utilisent
En plus du approve ordinaire, le EVM dispose de moyens d'accorder une autorisation sans transaction distincte. L'utilisateur simplement signe un message, et l'application utilise cette signature dans sa propre transaction, qui accorde à la fois le droit de dépenser et exécute l’action – échange, dépôt ou réclamation. Ces mécaniques sont appelées permit et des extensions telles que Permit2.
D'un point de vue UX, cela ressemble à moins d'étapes : il n'y a pas de transaction approve distincte et aucun gaz n'est requis pour un appel approve distinct. La conséquence technique est la même : un droit de dépenser apparaît dans le contrat, et ce droit peut rester actif au-delà d'une seule opération si les paramètres de signature fixent une limite large ou une expiration longue.
Les deux types de confirmation que les utilisateurs confondent le plus souvent :
- Transaction (en chaîne) : approve / revoke / transfert — envoyé au réseau, nécessite du gaz et change l'état du contrat.
- Signature du message (hors chaîne) : permit et mécanismes similaires : aucun gaz n'est nécessaire au moment de la signature, mais ils permettent à une application d'installer les mêmes droits d'accès.
| ⚙️ Mécanisme | 🧾 Ce que vous accordez | 📍Où il apparaît | ⚠️ Risque clé |
|---|---|---|---|
| Approve (ERC-20) | Limite de dépenses en jetons pour un spender | DEX, prêts, agriculture, ponts | allowance illimité reste actif jusqu'à revoke |
| Permis (EIP-2612 et analogues) | Autorisation via une signature sans approve distinct | Swaps « un clic », agrégateurs, interfaces DeFi | La signature semble « sûre » mais confère de vrais droits |
| SetApprovalForAll (NFT) | Accès mondial à toute la collection | Marchés, monnaies, jeux dApps | NFTs peut être transféré sans confirmations répétées |
Nuance clé : approve et permit conduisent au même résultat : une adresse spécifique reçoit le droit de gérer les actifs du propriétaire. Le formulaire de confirmation diffère : une transaction en chaîne ou une signature de message qui est ensuite utilisée dans une transaction.
Liste de contrôle de pré-signature (30 secondes) : un filtre rapide pour voir si une signature accorde des droits de dépense.
- Qu'est-ce qui est confirmé ? Permis ou approve signifie une autorisation d'accès.
- Qui a accès ? Regardez le spender ou le operator dans les paramètres, pas dans la conception du site.
- Quelle est la limite ? Illimité sur les jetons liquides augmente le montant des dépenses disponibles.
- Existe-t-il setApprovalForAll ? Pour NFTs, il s'agit de l'état operator complet sur la collection.
- Y a-t-il urgence ? La pression du temps est souvent utilisée pour obliger les gens à signer sans vérifier les paramètres.
Le permis et les « signatures sans gaz » modifient uniquement la forme de la confirmation. Une signature de message peut installer des droits d'accès aux jetons ou à NFTs tout comme approve, les paramètres de signature doivent donc être lus comme des autorisations.
Dans les schémas de phishing d'approbation typiques, l'utilisateur est amené à signer approve/permit ou
Schémas typiques de phishing par approbation : comment vous êtes conduit à la « bonne » signature
Ces systèmes utilisent des interfaces familières et des flux de travail standard, ce qui fait que l'octroi d'autorisations ressemble à une étape de service ordinaire.
Presque toutes les attaques suivent la même logique : d'abord, l'utilisateur est amené à une page qui ressemble à une interface dApp, puis la page demande une signature qui accorde un droit de dépense ou un droit operator, et ensuite l'autorisation active est utilisée pour retirer des actifs sans nouvelle confirmation.
La caractéristique clé est l’absence de demande directe d’envoi de virement. Au lieu d'un transfert, le site demande approve/permit ou
- Clone d'un service populaire
- Un faux domaine ou lien publicitaire mène à une copie visuellement similaire d’un DEX ou d’une place de marché.
- L'interface demande approve « pour échange » ou
setApprovalForAll "pour la liste NFT". - Les paramètres de signature contiennent un spender/operator qui n'appartient pas au service réel.
- Compromission des chaînes officielles
- Un lien est publié dans Discord, Telegram ou X au nom du projet ou d'un modérateur.
- Des déclencheurs d'urgence sont utilisés : « bug du contrat », « migration menthe », « dernière chance ».
- Le lien mène à une page qui demande à approve/permit l’adresse de l’attaquant.
- L’ingénierie sociale par le « support »
- L'attaquant envoie un message privé prétendant être un service d'assistance.
- Une signature est demandée sous prétexte « d’annuler une transaction bloquée ».
- En pratique, l'utilisateur signe un permit ou accorde approve à une adresse tierce.
- Substitution du sens de la signature
- La fenêtre du portefeuille affiche un appel technique sans explication claire de la part de l'interface.
- L'utilisateur confirme sans vérifier l'adresse spender/operator et la limite.
- Le risque est plus élevé lorsque l'interface n'affiche pas le spender, la limite ou le type d'autorisation.
Exemple : un utilisateur connecte un portefeuille à une page « airdrop », clique sur Réclamer et signe un approve illimité pour un stablecoin. Le solde ne change pas, mais plus tard, lorsque les fonds arrivent, le spender retire les jetons via
Ces attaques ne nécessitent pas un retrait immédiat. L'attaquant peut attendre que le solde augmente ou que les liquidités arrivent, puis utiliser l'autorisation active.
Les schémas typiques de phishing d'approbation déguisent l'octroi de droits en actions familières. Tant que le statut allowance ou operator est actif, l'attaquant peut l'utiliser à tout moment sans confirmation du nouveau propriétaire.
Allocation et
Erreurs courantes des utilisateurs : pourquoi les approbations s'accumulent et deviennent une menace
Le danger des approbations se fait rarement sentir au moment de la signature car approve ne modifie généralement pas la balance. Le risque apparaît plus tard, lorsqu’une autorisation active est utilisée pour dépenser, et devient plus fort si ces autorisations restent sur plusieurs réseaux et plusieurs tokens.
L'erreur la plus courante : approbations illimitées pour les pièces stables et les jetons liquides. Au moment de la signature, cela ressemble à moins d'étapes, mais techniquement, cela signifie un grand allowance qui permet au spender de dépenser des jetons via
La même logique s'applique à
Une classe distincte d’erreurs provient de la confiance dans la marque et dans la conception visuelle. L'utilisateur se concentre sur le domaine, le logo ou la mise en page, mais l'autorisation est toujours accordée à une adresse spécifique — spender ou operator. Si l'interface est remplacée, la conception ne modifie pas l'adresse dans les paramètres de signature.
Une autre erreur courante consiste à considérer le problème comme résolu après revoke dans un réseau. Les approbations sont isolées par réseau : allowance dans Ethereum et allowance dans Arbitrum sont des enregistrements différents dans des contrats différents, une autorisation peut donc rester active sur un autre réseau.
Si vous déplacez des liquidités entre réseaux, vérifiez les approbations après les opérations inter-chaînes : les ponts et les routeurs nécessitent souvent approve pour un spender distinct dans chaque réseau. Ponts cryptographiques : comment ils fonctionnent et lesquels sont les plus sûrs.
Les signatures sans gaz créent une confusion supplémentaire. Les permis et mécanismes similaires sont perçus comme des confirmations « douces », mais le résultat est le même : l'application a la possibilité d'installer une autorisation qui est ensuite utilisée pour les dépenses.
Les erreurs deviennent plus dangereuses lorsqu’un portefeuille est utilisé simultanément pour le stockage, le trading actif et les expériences. Dans ce mode, un spender/operator inutile crée un accès à des actifs qui ne faisaient pas partie de l'opération d'origine.
La principale menace liée aux approbations réside dans les autorisations actives qui restent dans les contrats une fois la tâche terminée. Un allowance illimité, un NFT activé et des autorisations sur plusieurs réseaux augmentent la quantité d'actifs disponibles pour les dépenses sans nouvelles confirmations.
Les autorisations doivent être vérifiées séparément pour chaque réseau : les listes allowance et operator dans Ethereum ne correspondent pas à Arbitrum, Optimism, Polygon ou BSC, car les enregistrements de droits sont stockés dans des contrats sur le réseau spécifique.
Où vérifier les autorisations : que faut-il inspecter exactement et dans quel ordre
L’examen des autorisations est une séquence d’étapes par réseau et type d’actif. Les jetons ERC-20 et NFTs utilisent des mécanismes d'accès différents, ils doivent donc être analysés séparément et fermés par ordre de priorité : adresses inconnues et limites larges d'abord, puis les autorisations de travail restantes.
- Identifiez le réseau avec le plus d’activité
- Les autorisations ne sont pas « globales » : Ethereum, Arbitrum, Optimism, Polygon et BSC ont des listes d'approbation distinctes.
- Commencez par le réseau où la liquidité est concentrée et où les dernières transactions ont eu lieu.
- Vérifiez les approbations ERC-20 et réduisez ce qui est inutile
- La priorité va aux spender inconnus et aux allowance illimités sur les stablecoins et les tokens liquides.
- Supprimez les autorisations inutilisées et réduisez les limites du montant nécessaire pour l’opération en cours.
- Vérifiez les approbations NFT séparément
- Portez une attention particulière à
setApprovalForAll pour les marchés et les jeux dApps. - Gardez un operator actif uniquement pendant la période où il est réellement nécessaire.
- Portez une attention particulière à
- Vérifiez les adresses que vous laissez actives
- Faites correspondre les adresses spender/operator avec les services de confiance par l'adresse dans la signature ou l'explorateur.
- Si une adresse n'est pas reconnaissable, réinitialisez le allowance ou désactivez le operator et accordez une nouvelle autorisation uniquement lorsque cela est nécessaire.
| Approche | Ce qu'il vérifie | Côté fort | Limitation |
|---|---|---|---|
| Scanner de blockchain réseau | Homologations ERC-20 allowance et souvent NFT | Données réseau, sans faire confiance à une interface dApp | Vous devez changer de réseau et analyser les adresses |
| Services Revoke | Autorisations de jeton et NFT dans le réseau sélectionné | Liste + bouton pour réinitialiser allowance/désactiver operator | La couverture dépend du réseau et des intégrations |
| Portefeuilles avec simulation | Dépensier, limites, avertissements avant de signer | Affiche quelle adresse recevra les droits avant la confirmation | Affichage de différentes profondeurs d'approbation |
Que rechercher dans une liste d'autorisations
- Inconnu spender ou operator. Si l'adresse n'est pas reconnaissable, il s'agit d'un candidat revoke.
- allowance illimité sur les liquidités. Un allowance important augmente le montant des dépenses disponibles.
- Autorisations dans L2s et sidechains. Les approbations peuvent rester actives sur les réseaux sur lesquels vous n'avez pas effectué de transactions depuis longtemps.
- NFT operators sans besoin actuel. Un operator actif peut transférer NFTs sans nouvelle confirmation.
- Contrats de procuration et mises à niveau. Approve est lié à l'adresse spender, donc une ancienne autorisation reste active même si la logique change lors d'une mise à niveau.
Logique de révision : Réinitialisez d'abord les allowance pour les adresses inconnues et supprimez les autorisations illimitées sur les jetons sensibles, puis réduisez les limites restantes au montant nécessaire aux opérations en cours.
L'examen des autorisations doit correspondre à la manière dont les autorisations sont stockées : réseaux distincts, jetons distincts, spender/operator distincts. La priorisation des autorisations inconnues et illimitées ferme les principaux scénarios de dépenses sans nouvelles confirmations.
Revoke est une transaction qui définit allowance sur 0 pour le propriétaire → spender → paire de jetons ou commutateurs
Comment obtenir correctement les autorisations revoke : jetons, NFTs et erreurs courantes
Revoke est une transaction en chaîne qui modifie allowance ou désactive un NFT operator. Du coup, le contrat enregistre un nouvel état : une adresse précise n'a plus le droit de gérer votre patrimoine. Revoke arrête les dépenses futures, mais n'annule pas les transactions déjà exécutées.
Algorithme revoke pas à pas pour ERC-20
- Identifiez le réseau. Les approbations sont isolées par réseau : Ethereum, Arbitrum, Optimism et autres L2s ont des listes d'autorisations distinctes.
- Recherchez le jeton et spender. Vérifiez l'adresse du contrat du jeton, le nom du jeton et la limite actuelle de allowance, en particulier pour les pièces stables et les actifs liquides.
- Exécutez revoke. L'option standard consiste à définir allowance sur 0 via approve(spender, 0) ou à utiliser un bouton revoke dans un service.
- Vérifiez le résultat. Assurez-vous que allowance est devenu 0 et que l'autorisation n'est plus affichée comme active.
Algorithme revoke étape par étape pour NFTs
- Ouvrez la liste de collecte operator. Rechercher des actifs
setApprovalForAll entrées et adresses operator associées. - Désactivez le operator. Le statut doit être basculé sur faux.
- Répétez l’opération pour les collections de clés. Vérifiez d’abord les collections ayant la valeur et la liquidité la plus élevée.
Erreur courante : revoke est effectué dans un réseau tandis que l'état allowance ou operator reste actif dans un autre. Si vous avez utilisé des ponts, des agrégateurs et des dApps multi-réseaux, vérifiez les approbations dans chaque réseau séparément.
ERC-20 nuance : certains jetons nécessitent la séquence approve(spender, 0) avant de définir un nouveau allowance. Dans ces cas, revoke commence par réinitialiser la limite.
Revoke modifie l'enregistrement des droits dans le contrat : allowance devient 0 ou le operator est désactivé. Pour que revoke ferme réellement l'accès, il doit être effectué dans le bon réseau et pour la bonne paire de jeton → spender ou de collection → operator.
Si vous avez accordé approve/permit ou
Si vous avez déjà accordé un approve dangereux : un plan rapide de réduction des dégâts
Dans cette situation, l'ordre des actions est important : éloignez d'abord les actifs des autorisations actives, puis réinitialisez allowance et désactivez operator, et seulement après cela, recherchez la source de la signature.
Si
- Déplacez les actifs vers une adresse « propre ». Un nouveau portefeuille avec une nouvelle phrase de départ rompt la connexion avec les approbations actuelles car allowance et operator sont liés à l'ancienne adresse du propriétaire.
- Autorisations Revoke sur l'adresse compromise. Réinitialisez d'abord allowance pour les pièces stables et les jetons liquides, puis pour les jetons restants.
- Vérifiez les autorisations NFT. Désactiver
setApprovalForAll pour les operator qui ne sont pas nécessaires. - Déconnectez les sessions dApp dans le portefeuille. Cela ne modifie pas allowance, mais supprime les sessions de site actives susceptibles de demander une autre signature.
- Isoler l'environnement. S'il existe un risque d'extension malveillante ou de substitution de site, utilisez un autre navigateur ou appareil.
N'acceptez pas les « transferts tests », les « contrôles de sécurité » ou la « récupération de fonds » suggérés par des inconnus. De telles demandes sont souvent utilisées pour obtenir une nouvelle signature ou un transfert direct.
Une fois qu'une autorisation dangereuse a été accordée, la priorité est de réduire la quantité d'actifs accessibles via allowance/operator, puis de réinitialiser ces droits avec les transactions revoke. Tant que les droits restent actifs, les dépenses peuvent avoir lieu sans nouvelles confirmations.
Empêcher le phishing d'approbation revient à contrôler deux paramètres : qui reçoit le droit (spender/operator) et quelle est l'étendue de ce droit (allowance ou
Prévention : comment accorder des autorisations sans devenir une cible facile
La prévention du phishing par approbation repose sur la gestion des autorisations : séparation des rôles de portefeuille, limitation de allowance et désactivation de operator une fois la tâche terminée.
La plupart des pertes sont liées aux autorisations actives qui restent dans les contrats une fois l'opération terminée : allowance illimité, NFT operator activé et l'habitude de confirmer les signatures sans vérifier l'adresse. Ces enregistrements de droits permettent de dépenser sans nouvelles confirmations jusqu'au revoke.
Séparer les rôles de portefeuille
L’utilisation d’une seule adresse pour le stockage, les échanges et les expériences rend tout approve critique pour l’intégralité du solde de cette adresse. La séparation des adresses limite la quantité d'actifs exposés via allowance ou operator. Si vous choisissez un wallet « stockage » sur le long terme, commencez par un examen du portefeuille matériel de cryptographie et configurez l'entreposage frigorifique avant le travail actif du DeFi.
🧩 Configuration de base à trois adresses
- Stockage (longue durée) : capital principal, interactions minimales dApp, aucune approbation active.
- Adresse opérationnelle : activité régulière de DeFi, solde limité, révision programmée des allowance et operator.
- Adresse expérimentale : parachutages, NFTs, nouveaux projets ; le risque est limité au montant qui y est stocké.
Réduire la portée de chaque autorisation
Même lorsque vous travaillez avec des services de confiance, envisagez le scénario d'une erreur ou d'une compromission spender/operator. Pour ERC-20, l'étendue du droit est définie par allowance ; pour NFTs, le périmètre est défini par
- Utilisez des limites exactes. L'allocation définit le nombre maximum de jetons qu'un spender peut dépenser.
- Réinitialisez allowance une fois la tâche terminée. Cela met fin aux dépenses jusqu'au
transferFrom . - Vérifiez l'adresse spender. L'autorisation est accordée à l'adresse dans les paramètres de signature, et non à un « site ».
- Désactivez setApprovalForAll après la tâche. L'opérateur ne doit pas rester actif après une inscription ou une session de jeu.
- Ne confirmez pas en raison de l'urgence. L'urgence est souvent utilisée pour que la signature ne soit pas inspectée.
Mode révision : quand vérifier les approbations
- Après une opération ponctuelle. Si le service n'est pas utilisé régulièrement, réinitialisez allowance ou désactivez operator une fois l'opération terminée.
- Pour une adresse DeFi opérationnelle. Avec une activité constante, examinez les approbations une à deux semaines et supprimez les autorisations inutiles.
- Pour une adresse expérimentale. Pour les nouveaux dApps et les parachutages, vérifiez et fermez les autorisations après chaque session.
Modèle de travail : approve/permit accorde un droit sur une adresse spécifique, allowance définit la limite, revoke modifie la limite à 0 ou désactive le operator.
La prévention de l'approbation est une gestion active des autorisations : la séparation des adresses, les limites exactes de allowance et la désactivation de operator après la tâche réduisent la quantité d'actifs disponibles pour les dépenses sans nouvelles confirmations.
Approve permet aux protocoles d'appeler
Approve en tant que mécanisme : points forts et risques inhérents
Approve est une base de l'infrastructure DeFi : il permet aux protocoles d'effectuer des opérations via
Le mécanisme approve est un compromis entre la conservation des actifs sur votre propre adresse et l'automatisation des actions de protocole. Les actifs restent à votre adresse, mais le contrat reçoit le droit de les dépenser dans le cadre du allowance défini dans approve.
✅ Points forts du approve
- Les actifs restent à l’adresse du propriétaire jusqu’à ce qu’ils soient dépensés
transferFrom . - Les protocoles peuvent effectuer des opérations sans signature pour chaque étape en utilisant allowance.
- L'allocation permet de limiter le montant maximum des dépenses pour un spender spécifique.
- Les autorisations sont vérifiables en chaîne et peuvent être réinitialisées avec une transaction revoke.
❌ Risques inhérents aux approbations
- Une autorisation reste active jusqu'à revoke et ne dépend pas de la fermeture d'un site ou de la déconnexion d'un portefeuille.
- Le allowance illimité augmente le nombre de jetons disponibles pour les dépenses si le spender est compromis.
- Si approve est signé sans vérifier le spender et la limite, le droit peut être accordé à la mauvaise adresse.
DéfinirApprobationPourTous pour NFTs donne à un operator le droit de transférer toute la collection en une seule action.
Approve est un mécanisme d'infrastructure pour la gestion des droits. C'est pratique car le transfert est exécuté via allowance sans signatures répétées, et risqué car une autorisation active fonctionne jusqu'à revoke et peut être utilisée pour des dépenses ultérieures.
Cas et leçons : pourquoi un « contrat correct » peut encore devenir un problème
Même lorsque vous travaillez avec des services légitimes, les approbations actives créent des risques : une vulnérabilité, une mise à niveau ou une substitution de front-end devient dangereuse si allowance est déjà enregistré ou si operator est activé dans le contrat.
La propriété clé des approbations est l’absence de « durée de vie ». Si une autorisation a été accordée, le contrat n'a pas besoin de redemander approve : il utilise les droits déjà enregistrés. Le risque dépend donc non seulement du service actuel, mais aussi de la liste des approbations accumulées sur l'adresse.
🔓 Cas 1 : vulnérabilité dans un protocole légitime + approbations illimitées
Un utilisateur accorde un approve illimité à un protocole, et plus tard un bug est découvert dans la logique de dépenses cela permet au contrat de dépenser plus de jetons que prévu.
- Le contrat comporte déjà les dépenses via allowance, l'attaque ne nécessite donc pas la signature d'un nouveau propriétaire.
- Le allowance illimité augmente le montant des dépenses jusqu'au solde symbolique à l'adresse du propriétaire.
- Les utilisateurs qui n'effectuent pas de nouvelles transactions restent vulnérables jusqu'à la réinitialisation du allowance.
Le approve illimité transforme un bug de protocole en un risque pour l'intégralité du solde de jetons sur l'adresse. Exact allowance limite les dépenses maximales et revoke termine correctement les dépenses.
🧩 Cas 2 : une mise à niveau d'un contrat proxy modifie le comportement d'accès
Les contrats évolutifs conservent la même adresse, mais le code à cette adresse peut changer après une mise à niveau ou un compromis de gouvernance.
- Approve est lié à l'adresse spender, et non à une version de code spécifique.
- Après une mise à niveau, le nouveau code peut utiliser allowance différemment de ce à quoi le propriétaire s'attendait.
- L'ancien allowance reste actif jusqu'à ce qu'il soit réinitialisé par une transaction.
Lors de la mise à niveau des protocoles, les anciennes approbations doivent être révisées car allowance reste actif sur la même adresse spender.
🧠 Cas 3 : substitution du frontend pendant que la marque reste familière
L'utilisateur visite un site familier, mais l'interface est remplacée par DNS, publicités, CDN ou extensions malveillantes.
- L'apparence visuelle de l'interface correspond à ce que l'utilisateur attend.
- Approve ou permit est accordé à une adresse qui n'est pas le contrat de service.
- La vérification de spender/operator dans la signature révèle la substitution ; la marque et le design ne le font pas.
Fiez-vous à l'adresse spender/operator et à la limite allowance dans la signature, et non à la conception du domaine et de la page.
🛰️ Cas 4 : agrégateurs et routeurs comme passerelle d'accès large
Les agrégateurs et les routeurs utilisent un seul spender pour de nombreux itinéraires et protocoles.
- Une adresse spender sert de nombreux scénarios et de nombreux jetons.
- Si le spender est compromis, le risque se propage à tous ceux qui l'ont accordé allowance.
- Le allowance illimité augmente le montant pouvant être dépensé via cette adresse.
Pour les routeurs, la limite allowance définit le montant maximum des dépenses, et le revoke standard supprime les anciennes autorisations qui ne sont plus nécessaires.
🖼️ Cas 5 : setApprovalForAll pour NFTs reste actif pendant des années
- Il s'agit du statut operator, et non d'une limite en nombre de NFTs.
- Même sans activité, le operator reste activé dans le contrat de collecte.
- La compromission du operator permet de transférer le NFTs sans nouvelle signature du propriétaire.
Désactivation
Un incident devient possible lorsqu'un allowance est déjà enregistré ou qu'un operator est activé dans le contrat. A ce moment-là, les dépenses peuvent être exécutées sans la signature d'un nouveau propriétaire.
En pratique, les incidents se produisent parce que les autorisations demeurent une fois les opérations terminées. Un examen régulier et la désactivation des allowance et operator inutiles limitent le montant des actifs disponible pour les dépenses sans nouvelle signature.
La FAQ permet de clarifier quelles signatures accordent des droits et comment fonctionne revoke. et pourquoi des dépenses peuvent avoir lieu sans confirmation répétée.
FAQ sur le phishing par approbation, approve et revoke
Pourquoi les gens disent-ils « vidé sans signature » si j’ai signé quelque chose ?
La signature visait à accorder des droits et non à transférer des fonds. Après approve, permit ou
Le approve illimité est-il toujours une erreur ?
Illimité approve enregistre une valeur très importante dans allowance. Cela augmente le nombre maximum de jetons que le spender peut dépenser.
revoke peut-il restituer les fonds volés ?
Non. Revoke change l'état du contrat uniquement pour le futur : allowance devient 0 ou operator est désactivé. Les transactions déjà exécutées ne sont pas annulées.
La suppression du portefeuille ou la « déconnexion du site » supprime-t-elle les approbations ?
Non. Les autorisations sont stockées en chaîne dans les contrats de jeton et NFT. La déconnexion d'un site ou la suppression d'une application ne modifie pas le statut allowance ou operator dans le contrat.
Où exactement approve est-il stocké ?
En état de contrat intelligent. Pour ERC-20, il s'agit de l'enregistrement allowance (propriétaire, spender) ; pour NFTs, il s'agit des approbations et des operator dans le contrat de collecte.
approve peut-il être limité à un montant spécifique ?
Oui. L'appel approve transmet le paramètre montant et cette valeur définit allowance. Le spender ne peut pas dépenser plus que les allowance permit actuels.
Qu'est-ce qui est le plus dangereux : approve pour un token ou setApprovalForAll pour un NFT ?
Habituellement
Les approbations doivent-elles être vérifiées dans L2s et les sidechains ?
Oui. Chaque réseau stocke ses propres enregistrements de droits dans ses propres contrats. L'allocation dans Ethereum et allowance dans Arbitrum sont des valeurs différentes, donc la vérification d'un seul réseau n'affiche pas les autorisations dans les autres réseaux.
Un portefeuille matériel protège-t-il contre le phishing par approbation ?
Un portefeuille matériel protège la clé privée et le processus de signature contre le vol sur l'appareil, mais il ne change pas le sens de l'action signée. Un approve/permit dangereux ou
La FAQ se résume à une différence vérifiable : une signature peut accorder des droits (approve/permit/
Un approve/permit erroné ou
Comment vous protéger contre le phishing d'approbation et garder les autorisations sous contrôle
Les autorisations sont la base de la mécanique de DeFi, mais les statuts allowance et operator sont exactement ce qui permet de retirer les actifs sans signature répétée si le droit a été accordé à une adresse inutile.
Phishing d'approbation constitue un abus de droits légitimes. Un approve/permit ou
Pour éviter de laisser des droits actifs sur une adresse, gardez le contrôle par des actions concrètes :
- Vérifiez l'adresse d'accès. La partie importante est spender/operator dans la signature et dans la liste d'approbations, pas la marque ou le design.
- Limite allowance. Définissez une limite spécifique à la tâche au lieu d'une limite illimitée et réinitialisez allowance lorsque le droit n'est plus nécessaire.
- Désactivez operator pour NFTs. Ne pars pas
setApprovalForAll activé une fois l’action terminée. - Vérifiez tous les réseaux. L'allocation et operator sont stockés séparément dans chaque réseau. Examinez donc chaque réseau sur lequel un dApp a été utilisé.
- Séparez les adresses par rôle. Le solde sur une adresse définit le montant maximum pouvant être dépensé via des droits actifs sur cette adresse.
Traitez les approbations comme des droits d’accès actifs enregistrés dans les contrats. Les limites minimales de allowance, les operator désactivés et l'examen sur tous les réseaux réduisent la quantité d'actifs disponibles pour les dépenses sans nouvelle signature.