Comment les autorisations de jetons malveillantes sont utilisées pour vider un portefeuille

Presque toute interaction avec une application décentralisée, qu'il s'agisse de trader sur une plateforme d'échange décentralisée ou de mettre un jeton en staking, exige d'accorder à cette application la permission de déplacer un jeton précis au nom du propriétaire du portefeuille. Cette permission s'appelle une autorisation de jeton, et elle constitue un élément légitime et nécessaire du fonctionnement de la plupart des applications blockchain. Le problème n'est pas que les autorisations existent. Le problème est que la plupart des interfaces de portefeuille les présentent brièvement et de manière technique, et que la plupart des utilisateurs les confirment rapidement sans comprendre exactement ce qu'ils autorisent.

Selon le rapport 2026 sur la criminalité crypto de Chainalysis, les arnaques on-chain ont rapporté au moins quatorze milliards de dollars en 2025, contre douze milliards l'année précédente, et le phishing par autorisation a été un contributeur constant à ce chiffre, avec plus d'un milliard de dollars de pertes cumulées signalées depuis 2021 attribuées spécifiquement à cette technique.

Ce qu'une autorisation de jeton accorde réellement

Lorsqu'une application demande une autorisation, elle demande au portefeuille d'autoriser un contrat intelligent à transférer jusqu'à un montant précis d'un jeton, au nom du propriétaire, au moment choisi par le contrat. De nombreuses applications demandent par défaut une autorisation illimitée, car cela est plus pratique pour l'application et évite de demander à l'utilisateur de réapprouver chaque future transaction. C'est précisément cette commodité qui rend la permission dangereuse si le contrat qui la reçoit est malveillant ou est compromis ultérieurement, car l'autorisation elle-même n'expire pas et ne nécessite aucune confirmation supplémentaire pour être exercée.

Les autorisations ERC-20, Permit et Permit2 expliquées

La fonction approve standard

La norme de jeton ERC-20 d'origine inclut une fonction appelée approve, que le propriétaire d'un portefeuille appelle pour autoriser une adresse de contrat précise à dépenser jusqu'à un montant défini de ce jeton. Cela nécessite une transaction on-chain, ce qui signifie que cela coûte des frais de réseau et est enregistré de façon permanente sur la blockchain dès sa confirmation. Comme il s'agit d'une transaction visible et distincte, la plupart des interfaces de portefeuille afficheront au moins un avertissement générique indiquant qu'une interaction avec un contrat, plutôt qu'un simple transfert, est demandée.

Permit et signatures hors chaîne

Une norme plus récente, communément appelée Permit, permet d'accorder le même type d'autorisation via un message signé plutôt qu'une transaction on-chain. La signature elle-même ne coûte aucun frais de réseau et n'a pas besoin d'être diffusée immédiatement, car le contrat destinataire peut la présenter à la blockchain à tout moment ultérieur pour activer l'autorisation. C'est pratique pour les applications légitimes, car cela permet à un utilisateur d'approuver et de réaliser une action, comme un échange de jetons, en une seule interaction au lieu de deux transactions distinctes. C'est aussi précisément ce qui rend le phishing basé sur Permit plus difficile à repérer, car une demande de signature ressemble souvent visuellement à la signature d'un message anodin, et de nombreuses interfaces de portefeuille ont historiquement affiché moins de détails pour une demande de signature que pour une transaction complète.

Permit2 et les autorisations universelles

Permit2, une extension supplémentaire largement adoptée par les plateformes d'échange décentralisées, permet à une seule autorisation accordée à un contrat Permit2 central d'être ensuite réutilisée sur de nombreuses applications différentes sans autorisation distincte pour chacune. Cela réduit les frictions et les frais pour les utilisateurs légitimes, mais cela signifie également qu'une seule signature Permit2 hameçonnée peut potentiellement exposer un jeton à toute application conçue pour interagir avec le système Permit2, élargissant le rayon d'action pratique d'une tentative de phishing réussie par rapport à une ancienne autorisation à contrat unique.

Un scénario réaliste : un faux airdrop qui accorde une autorisation illimitée

• Un message circule dans une communauté crypto affirmant qu'un projet de jeton bien connu distribue un airdrop surprise aux détenteurs d'un actif lié, avec un lien vers une page de réclamation.
• La page de réclamation demande au visiteur de connecter son portefeuille et de cliquer sur un bouton intitulé Réclamer maintenant, ce qui déclenche une fenêtre contextuelle de portefeuille demandant une autorisation pour le jeton du projet, décrite uniquement comme une interaction avec un contrat.
• Le montant d'autorisation demandé est fixé à la valeur maximale possible que permet la norme du jeton, plutôt qu'à un montant précis de réclamation, bien que ce détail ne soit pas mis en évidence dans l'écran de confirmation par défaut du portefeuille.
• La victime confirme, ne reçoit aucun jeton puisqu'il n'y a jamais eu de véritable airdrop, et ferme l'onglet en supposant que la réclamation a simplement échoué ou était déjà épuisée.
• Des semaines plus tard, une fois que le prix du jeton a augmenté ou que la victime a accumulé un solde plus important, l'attaquant exerce l'autorisation permanente et transfère la totalité du solde en une seule transaction que la victime n'a jamais approuvée directement.

Le délai entre l'interaction de phishing initiale et la perte finale est délibéré. Il déconnecte le vol de sa cause dans la mémoire de la victime et rend la page de phishing spécifique beaucoup moins susceptible d'être signalée ou reliée à la perte lorsqu'elle se produit finalement.

Pourquoi le phishing par autorisation est plus difficile à remarquer qu'un transfert direct de vidangeur

Un vidangeur de portefeuille direct, traité dans notre guide complémentaire, vide généralement un portefeuille en quelques secondes après la confirmation d'une signature, ce qui rend au moins la cause et l'effet immédiatement évidents pour la victime. Le phishing par autorisation est structuré différemment. La transaction d'autorisation elle-même ne déplace rien, de sorte qu'une victime qui vérifie son solde juste après avoir confirmé ne voit aucun changement et conclut raisonnablement qu'il ne s'est rien passé. La perte réelle peut survenir des jours, des semaines, ou des mois plus tard, exécutée par l'attaquant au moment de son choix, ce qui signifie que le lien entre la page de phishing d'origine et le vol final n'est fréquemment jamais établi par la victime. C'est aussi pourquoi les audits d'autorisation réguliers comptent davantage pour cette menace spécifique que pour les attaques directes par vidage, puisqu'il existe une véritable fenêtre, bien que de durée incertaine, pendant laquelle révoquer l'autorisation empêche toute perte de se produire.

Comment l'attaque est généralement menée

Fausses pages de réclamation et de vérification

Le montage le plus courant est une page imitant une réclamation d'airdrop, une étape de vérification de portefeuille, ou une interaction de protocole routinière. La victime connecte son portefeuille en s'attendant à une simple confirmation, et le site demande à la place une autorisation couvrant un jeton de valeur, présentée dans la fenêtre contextuelle du portefeuille comme une interaction générique avec un contrat plutôt que comme quelque chose d'alarmant.

Phishing par signature Permit et Permit2

Une variante plus récente et plus difficile à détecter exploite une norme de signature, souvent appelée Permit ou Permit2, qui permet d'accorder une autorisation via un message signé hors chaîne plutôt qu'une transaction on-chain. Comme la signature d'un message ne déclenche pas toujours les mêmes avertissements visuels qu'une transaction, et ne coûte aucun frais de réseau, les victimes sont plus susceptibles de la signer sans examen attentif. Un cas largement rapporté concernait un trader ayant perdu environ un million de dollars en une seule signature Permit2 après l'avoir confondue avec une confirmation routinière sur l'interface d'une plateforme d'échange décentralisée.

Exploitation différée

Comme une autorisation n'a pas besoin d'être utilisée immédiatement, les attaquants récoltent fréquemment un grand nombre d'autorisations sur de nombreux portefeuilles et les exercent plus tard, par lots, souvent au moment où le prix d'un jeton a augmenté ou lorsque la victime est moins susceptible de surveiller activement ce portefeuille. Ce délai explique en partie pourquoi les victimes ne parviennent parfois pas à relier une perte à l'interaction de phishing d'origine, puisque des semaines ou des mois peuvent séparer les deux événements.

Comment vérifier et révoquer les autorisations existantes

• Utiliser un outil de vérification des autorisations réputé qui lit l'historique d'autorisations on-chain de votre portefeuille et répertorie chaque permission active, ainsi que le contrat qui la détient et le montant qu'elle couvre.
• Révoquer toute autorisation que vous ne reconnaissez pas ou dont vous n'avez plus besoin, en particulier les autorisations illimitées liées à des contrats inconnus ou rarement utilisés.
• Prêter une attention particulière aux autorisations de type Permit2, car elles sont moins visuellement apparentes dans la plupart des interfaces de portefeuille qu'une transaction d'autorisation on-chain standard.
• Faire de la révocation une pratique routinière après toute interaction avec une application décentralisée nouvelle ou inconnue, et non quelque chose fait uniquement de manière réactive après la découverte d'une perte.

Au-delà de la vérification des autorisations existantes, quelques signes précis au moment où une nouvelle autorisation est demandée méritent d'être traités comme un signal d'arrêt immédiat plutôt que comme quelque chose à examiner plus tard.

• Le montant demandé pour l'autorisation est la valeur maximale que permet la norme du jeton, plutôt qu'un nombre précis lié à l'action revendiquée.
• La page demande une autorisation avant de montrer un quelconque avantage, récompense ou service tangible, plutôt que comme une deuxième étape naturelle d'une interaction que vous avez initiée.
• La fenêtre contextuelle du portefeuille décrit la demande uniquement comme une signature ou une interaction générique avec un contrat, sans résumé lisible par un humain de ce qui est autorisé.
• Le site combine urgence, comme un compte à rebours ou une fenêtre de réclamation limitée, avec une demande d'autorisation de portefeuille plutôt qu'une transaction directe.

Un guide complet du processus de révocation lui-même, y compris les outils couramment utilisés et la manière d'interpréter ce que chaque autorisation autorise réellement, est traité dans notre guide dédié sur la révocation des autorisations de jetons. Ce processus est l'une des rares mesures défensives réellement efficaces à la disposition d'un détenteur de portefeuille, car il ferme directement un accès permanent plutôt que de reposer uniquement sur l'évitement de futures tentatives de phishing.

Lorsqu'une autorisation a déjà été exploitée

Si des fonds ont déjà été déplacés via une autorisation exploitée, l'autorisation elle-même doit tout de même être révoquée immédiatement pour empêcher que le solde restant ne soit utilisé à nouveau, même après un premier vol. La transaction qui a exécuté le vol, ainsi que la transaction d'autorisation d'origine, devraient être documentées avec des horodatages et des identifiants, car cette séquence est souvent ce qui permet à un enquêteur d'établir comment la compromission s'est produite et si elle s'inscrit dans un schéma plus large d'activité de vidage, traité plus en détail dans notre guide sur les attaques de vidage de portefeuille.

Questions fréquentes

Sources et lectures complémentaires

• What are token approvals · MetaMask
• 2026 Crypto Crime Report: Scams · Chainalysis
• Uniswap Permit2 Phishing: $1 Million Loss Highlights Risk · Cryptonomist

Articles liés