Checklist de sécurité DeFi avant de signer une transaction

Pourquoi une checklist de sécurité DeFi compte plus qu'un « bon projet »

Si vous avez passé un peu de temps sur crypto Twitter, vous avez vu des posts qui ressemblent à des avis de décès : un portefeuille vidé, une approbation de token exploitée, un faux site d'airdrop, un pont qui a discrètement envoyé les fonds à un attaquant. Le détail qu'on omet presque toujours, c'est que c'est l'utilisateur, pas le protocole, qui a cliqué sur le dernier bouton. Le protocole peut être honnête, audité et bien connu, et vous pouvez tout perdre quand même en signant la mauvaise chose au bon endroit.

Cela peut sembler décourageant, mais c'est en réalité une bonne nouvelle. Cela signifie que le mode d'échec est humain et procédural, pas cryptographique. Il n'y a pas d'exploit à patcher, pas de zero-day à attendre. Il y a une routine à construire, et cette routine tient sur une fiche bristol. L'objectif de cette checklist de sécurité DeFi est de vous donner cette routine : un petit ensemble de vérifications à effectuer dans le même ordre, à chaque fois, avant de signer une transaction dans un portefeuille en self-custody.

Avant de parcourir les sept étapes, il est utile de nommer ce contre quoi vous vous défendez réellement. Trois schémas sont responsables de l'écrasante majorité des pertes concrètes pour les utilisateurs du quotidien, et chacun est traité par une étape spécifique plus loin dans cet article.

• Le phishing et les sites clones. Un domaine qui semble identique à un vrai, mais enregistré par un attaquant. Un résultat de recherche, une publicité ou un lien sponsorisé peut vous y envoyer.
• Les approbations mal comprises. Vous signez une approbation de token qui donne à un contrat la permission de déplacer un token depuis votre portefeuille, parfois en quantité illimitée, et cette permission vit sur la chaîne jusqu'à ce que vous la révoquiez.
• Des transactions qui ressemblent à de simples signatures mais font quelque chose d'inattendu. Un bouton « claim airdrop » qui est en fait une approbation de token, un « swap » qui est une signature de type permit laissant un tiers déplacer vos fonds, ou un pont qui dépose dans un contrat doté d'une porte dérobée.

Les vrais risques : comment les utilisateurs DeFi perdent réellement de l'argent

Il vaut la peine d'être concret sur les modes d'échec, car les avertissements abstraits sur l'importance de « faire ses propres recherches » ne changent pas les comportements. Quelques schémas sont responsables de la plupart des pertes, et chacun est évitable grâce à une habitude précise.

Les drains basés sur des approbations sont de loin la catégorie la plus importante. Lorsque vous swappez un token sur un exchange décentralisé, le site vous demande généralement d'approuver le contrat du router à dépenser ce token en votre nom. Cette approbation est stockée sur la chaîne et persiste d'une session à l'autre. Si le contrat du router est ensuite mis à jour, détourné, ou n'a jamais été digne de confiance, l'attaquant peut appeler transferFrom sur cette approbation et déplacer vos tokens à tout moment. Les approbations illimitées sont pratiques, mais elles constituent aussi une responsabilité durable. Une règle empirique utile : traitez chaque approbation comme une clé que vous remettez à un inconnu, et demandez-vous combien de temps vous voulez que cette clé reste valable.

Les signatures de type permit (EIP-2612) et les signatures off-chain ajoutent une seconde couche. Certaines dapps vous demanderont de signer un message plutôt qu'une transaction. Le message peut ressembler à du charabia, mais il peut accorder le même pouvoir de dépense qu'une approbation, sans coût de gas et sans trace sur la chaîne par défaut. Des outils qui décodent les signatures existent précisément parce que ce format est facile à détourner. Si vous signez un permit depuis un site malveillant, l'attaquant peut le soumettre on-chain plus tard et déplacer vos tokens sans aucune autre interaction de votre part.

Les ponts et les swaps cross-chain sont un troisième point chaud. Transférer de l'ETH du mainnet vers ARB ou vers des versions wrapped de SOL implique généralement de verrouiller des fonds dans un contrat sur la chaîne source et de minter un équivalent wrapped sur la destination. Des bugs dans les contrats de pont ont généré certaines des plus grosses pertes de l'histoire de la DeFi, et la surface d'attaque est plus large que celle d'un swap classique. Les opérations de pont sont aussi souvent celles où les utilisateurs tolèrent le plus de frictions, ce qui est précisément le moment où les escrocs poussent le plus fort.

Enfin, il y a le bon vieil échec d'hygiène du portefeuille. Un seul hot wallet utilisé pour signer des approbations pour vingt dapps différentes sur deux ans est un point de défaillance unique. Révoquer les anciennes approbations est une habitude réellement utile, pas de la paranoïa. Des sites comme revoke.cash existent pour faciliter cette démarche, et un passage trimestriel sur ces outils vaut largement les dix minutes qu'il prend.

Étape 1 : atterrir sur la bonne URL, à l'ancienne

Avant toute autre chose, vérifiez que vous êtes sur le vrai site. La plupart des hameçonnages ne sont pas ingénieux : il s'agit d'une annonce payante dans un moteur de recherche ou d'un post sponsorisé sur les réseaux sociaux qui renvoie vers un domaine ne différant du vrai que d'un caractère, ou d'un caractère Unicode visuellement identique. Le « l » d'une URL n'est pas forcément un L minuscule latin. Il peut s'agir d'un caractère cyrillique au rendu identique. La seule défense fiable consiste à ne jamais arriver sur un site DeFi via un lien que vous n'avez pas vous-même contrôlé.

Saisissez le domaine vous-même dans la barre d'adresse, ou utilisez un favori que vous avez créé lors de votre première visite sur le site légitime. Si quelqu'un dans un salon Discord vous envoie un lien vers « la page d'airdrop », considérez-le comme malveillant tant que le contraire n'est pas prouvé, aussi plausible que le nom d'utilisateur puisse paraître. Vérifiez l'URL caractère par caractère. Confirmez le contrat sur un explorateur de blocs tel qu'Etherscan avant de connecter votre portefeuille ou de signer quoi que ce soit ; l'adresse du contrat affichée sur la page vérifiée de l'explorateur fait foi, et non l'adresse indiquée dans une fenêtre contextuelle ou un tweet.

Deux habitudes supplémentaires aident. Premièrement, ajoutez le vrai domaine à vos favoris dès le premier jour, et ne cliquez jamais sur un lien qui contourne ce favori. Deuxièmement, si un site vous demande de connecter un portefeuille, l'invite de connexion dans votre portefeuille est le moment de marquer une pause, et non celui d'accélérer. Lisez l'invite du portefeuille, pas seulement la page web.

Étape 2 : comprendre précisément l'autorisation demandée

Une autorisation (approval) est une permission distincte et persistante sur la chaîne. Lorsque vous en signez une, vous n'effectuez pas une seule transaction. Vous indiquez à un smart contract que, dès maintenant et jusqu'à révocation ou utilisation de l'autorisation, il peut déplacer un montant précis d'un token précis hors de votre portefeuille en votre nom. Si vous autorisez le mauvais contrat, l'attaquant pourra vider ce token plus tard, sans aucune autre action de votre part.

La plupart des portefeuilles, y compris les principaux, affichent désormais le montant en clair dans l'écran de confirmation. Le chiffre à surveiller est le deuxième, et non le premier. Si le site indique « échanger 100 USDC contre de l'ETH » et que l'invite du portefeuille dit « autoriser USDC sans limite », on vous demande plus que ce que l'échange nécessite. Pour les contrats importants ou inconnus, définissez une allocation personnalisée qui couvre tout juste l'échange, puis révoquez-la ensuite. La friction est réelle. L'alternative est pire.

Faites particulièrement attention aux autorisations concernant des stablecoins comme USDC et USDT, et des tokens de grande valeur comme ETH. Une autorisation illimitée d'USDC à un routeur malveillant revient fonctionnellement à remettre à quelqu'un un chèque en blanc signé sur votre solde de stablecoins. Notez également que certains dapps utilisent désormais des signatures permit2 ou EIP-2612 à la place des autorisations on-chain, qui peuvent présenter le même risque sans apparaître dans une liste d'autorisations classique. Si un site vous demande de signer un message plutôt qu'une transaction, traitez-le avec la même méfiance qu'une autorisation illimitée.

Étape 3 : simuler la transaction avant de signer

Les outils de simulation exécutent votre transaction dans un bac à sable à partir de l'état actuel de la chaîne et vous montrent ce qu'elle va faire : quels contrats seront appelés, quels tokens seront déplacés et à quoi ressembleront vos soldes après. Deux options connues sont Tenderly et Blowfish, et de nombreux portefeuilles intègrent désormais la simulation. Si votre portefeuille dispose d'un panneau de simulation, lisez-le. Sinon, exécutez d'abord la transaction dans un simulateur externe.

Ce qu'il faut chercher, c'est toute ligne qui ne correspond pas à votre intention. Si vous aviez l'intention d'échanger 100 USDC contre de l'ETH et que la simulation montre qu'un autre token est déplacé, ou un autre montant, ou qu'une autorisation est définie, arrêtez-vous. Si la simulation montre que la transaction échouera on-chain, vous économiserez du gas et du temps en ne l'envoyant pas. Si elle montre un appel de contrat vers une adresse que vous ne pouvez pas identifier, ne signez pas.

La simulation n'est pas une baguette magique. Des attaquants sophistiqués peuvent concevoir des transactions dont le comportement malveillant ne se déclenche que sous certaines conditions, et une simulation statique peut ne pas le détecter. Mais pour le cas courant d'un utilisateur sur le point de faire une faute de frappe ou d'atterrir sur un site de phishing, la simulation est l'une des habitudes au meilleur rapport efficacité/prix que vous puissiez acquérir — et elle est gratuite.

Étape 4 : utiliser un portefeuille de « navigation », distinct de votre portefeuille de « signature »

Les configurations à portefeuille unique sont la raison la plus fréquente pour laquelle une petite erreur devient une perte totale. La solution est structurelle : gardez un portefeuille pour vos interactions DeFi au quotidien, et un second, alimenté uniquement lorsque c'est nécessaire, pour le stockage. C'est l'habitude la plus importante de toute la liste, et la plus facile à repousser à plus tard.

Concrètement : votre portefeuille de « navigation » ou « chaud » contient de petits montants, se connecte aux dapps et signe des autorisations. Votre portefeuille « coffre-fort » ou « froid » contient l'essentiel de vos fonds et se connecte rarement à quoi que ce soit. Lorsque vous souhaitez faire quelque chose d'important, vous n'envoyez que le montant nécessaire depuis le coffre-fort vers le portefeuille chaud, vous effectuez l'opération, puis (le cas échéant) vous renvoyez le solde restant. Si le portefeuille chaud est compromis, la perte est plafonnée à ce qu'il contenait à ce moment-là.

Ce schéma vous permet aussi d'utiliser un portefeuille vierge pour vos premières interactions avec un nouveau protocole. La première fois que vous visitez un site, le risque d'atterrir sur une variante de phishing est maximal. Faire cette première visite avec un portefeuille vide ne vous coûte rien si cela tourne mal. Ce n'est qu'après avoir vérifié le contrat, ajouté l'URL à vos favoris et vu une transaction aboutir que vous pouvez envisager d'y transférer de vrais fonds.

La même logique s'applique aux chaînes auxquelles vous ne faites pas encore confiance. Si vous essayez pour la première fois un nouveau pont vers SOL, faites-le depuis un portefeuille qui ne contient qu'un petit montant, et non depuis celui qui détient votre stack principal. Les nouvelles chaînes, les nouveaux contrats et les nouveaux ponts sont les endroits où le phishing le plus agressif a tendance à se concentrer.

Étape 5 : Attention à la chaîne et à l'actif

Une part étonnamment importante des tickets de support « où sont passés mes tokens » viennent d'une simple incompatibilité de chaîne. L'utilisateur a connecté son portefeuille, vu un solde qui semblait correct, et approuvé une transaction sur une chaîne sur laquelle il n'avait pas l'intention de se trouver. Le cas le plus fréquent est ETH sur le mainnet face à un L2 comme ARB, ou une chaîne EVM face à SOL : le format d'adresse est similaire, la dapp est similaire, l'URL est similaire, et l'utilisateur ne remarque pas à quel réseau son portefeuille est connecté à ce moment-là.

Vérifiez l'indicateur de réseau dans votre portefeuille à chaque transaction. Vérifiez le symbole de l'actif : « USDC » sur le mainnet n'est pas le même contrat que « USDC » sur ARB, et aucun des deux n'est la version bridgée frappée par un bridge tiers. Si un site indique qu'il accepte USDC et que votre portefeuille affiche l'USDC du mauvais réseau, l'approbation que vous êtes sur le point de signer peut concerner un token que le site ne peut en réalité pas recevoir, ou pire, un token que le site peut recevoir et revendre à son profit.

Pour SOL, les mêmes réflexes s'appliquent. Les portefeuilles SOL affichent un indicateur de réseau clair, et l'univers des tokens SPL est suffisamment vaste pour qu'un token de phishing puisse en imiter un vrai. Vérifiez l'adresse de mint du token sur un explorateur de blocs plutôt que de faire confiance au symbole affiché dans une liste. Le même principe s'applique à tous les écosystèmes : l'identifiant on-chain fait foi, le symbole n'est qu'une étiquette.

Étape 6 : Révoquer les anciennes approbations selon un calendrier

Les approbations sont persistantes. Une fois que vous avez donné à un contrat la permission de déplacer vos USDC, cette permission reste active jusqu'à ce que vous la révoquiez, même si vous n'utilisez plus jamais la dapp. Si le contrat est ensuite exploité, mis à jour de manière malveillante, ou s'il a toujours été une arnaque, vos tokens restent accessibles via cette ancienne approbation. C'est pourquoi une révocation périodique fait partie de la routine, et n'est pas une corvée ponctuelle.

Des outils comme revoke.cash rendent cette opération simple. Ils lisent la chaîne, listent toutes les approbations en cours, et vous permettent de soumettre une transaction de révocation pour chacune d'elles. Une cadence raisonnable est d'une fois par trimestre, ou immédiatement après toute interaction avec une dapp que vous ne prévoyez pas de réutiliser. La révocation coûte du gaz, mais quelques dollars de gaz sont un petit prix comparé à la perte du solde sous-jacent.

Deux remarques pratiques. D'abord, vous n'avez pas besoin de révoquer toutes les approbations à chaque fois ; concentrez-vous sur les approbations illimitées et sur les contrats que vous ne reconnaissez plus. Ensuite, lorsque vous révoquez, vous confirmez aussi que la dapp fonctionne toujours, ce qui est un effet secondaire utile : une dapp qui s'est éteinte a peut-être laissé ses contrats sous un nouveau contrôle, et au moment où vous y retournez pour révoquer, vous pouvez mettre à jour vos favoris en conséquence.

Étape 7 : Lire la demande du portefeuille, à chaque fois

L'écran de confirmation du portefeuille est la dernière ligne de défense, et c'est celle que les utilisateurs ignorent le plus souvent. C'est pourtant là qu'apparaissent les informations les plus pertinentes : l'adresse du contrat appelé, la fonction invoquée, l'actif et le montant, ainsi que toute charge utile de signature. La lire ne prend que quelques secondes. Ne pas la lire peut tout coûter.

Concrètement, vérifiez quatre éléments. L'adresse du contrat : collez-la dans un explorateur de blocs et confirmez qu'il s'agit bien du contrat attendu, avec le statut de vérification attendu. La fonction : « approve » est différent de « swap », et une signature « permit » est encore différente. Le montant : un nombre personnalisé est différent de « unlimited », et « 0 » signifie généralement que vous signez une annulation, ce qui est correct. L'adresse de destination : si la demande affiche un transfert vers une adresse que vous ne reconnaissez pas, arrêtez-vous.

Si l'un de ces quatre contrôles ne correspond pas à votre représentation mentale de ce que vous faites, ne signez pas. Fermez la demande, revisitez le site depuis votre favori, et recommencez. La phrase la plus coûteuse de la DeFi est « je suis sûr, signez ». La moins chère est « laissez-moi relire ».

Que faire en cas de problème

Même avec une routine parfaite, des erreurs arrivent. La réponse compte autant que la prévention, et les premières minutes sont celles qui comptent. Si vous réalisez en pleine signature que quelque chose ne va pas, ne signez pas. Si vous avez déjà signé et soupçonnez maintenant l'approbation, allez directement sur revoke.cash et révoquez l'approbation depuis un appareil sain. Si les fonds ont déjà bougé, ils sont généralement irrécupérables on-chain, et toute personne qui vous contacte en promettant de les récupérer contre des frais est en train de perpetrer une deuxième arnaque par-dessus la première.

Au-delà de l'immédiat, quelques habitudes rendent les incidents futurs survivables. Gardez une trace écrite de quel portefeuille détient quoi, afin de pouvoir agir vite sans avoir à reconstituer l'information sous le stress. Gardez un petit solde « premier essai » dans tout nouveau portefeuille que vous utilisez. Entraînez-vous une fois au flux de révocation, sur une approbation de test, avant d'en avoir besoin sous pression. Rien de tout cela n'est palpitant. Tout cela fonctionne.

Le résumé honnête est celui-ci : la sécurité en DeFi ne consiste pas à trouver un protocole qui ne peut pas être attaqué, car un tel protocole n'existe pas. Elle consiste à réduire la portée des erreurs que vous commettrez inévitablement, et à rendre le coût de ces erreurs suffisamment faible pour qu'elles soient récupérables. La checklist ci-dessus est une routine petite et ennuyeuse. C'est précisément le but. Les routines ennuyeuses sont celles que les gens suivent vraiment.

Comment suivre la sécurité DeFi de façon intelligente

La DeFi évolue vite, tout comme l'actualité qui l'entoure : nouveaux exploits, campagnes de phishing récentes, mises à jour de contrats, fermetures de bridges. Suivre le signal manuellement, surtout sur plusieurs blockchains comme Ethereum, Arbitrum et Solana, est une bataille perdue d'avance. Zippfeed fait remonter les titres DeFi et sécurité avec une notation de sentiment (bullish, neutre ou bearish) et une cote d'importance, pour que vous puissiez repérer les protocoles à risque et les alertes de sites copiés avant qu'ils n'atteignent votre portefeuille, et non après. Associez ce flux à la checklist ci-dessus, et la routine fastidieuse devient rapide.

Questions fréquentes

La DeFi est-elle sûre pour les débutants ?

La DeFi est plus sûre pour les débutants qui suivent une routine, et plus risquée pour ceux qui la traitent comme un simple site web. La technologie elle-même est auditée et on-chain, mais l'utilisateur reste la dernière ligne de défense contre le phishing, les mauvaises approbations et les sites copiés. Si vous débutez, commencez avec un petit solde dans un portefeuille de « navigation » séparé et ne déplacez des fonds plus importants qu'après avoir utilisé un protocole avec succès plusieurs fois. Ceci est une ressource éducative, pas un conseil financier ; faites toujours vos propres recherches avant de signer une transaction.

Comment fonctionne concrètement une approbation de token ?

Une approbation est un message on-chain qui autorise un smart contract à déplacer un token précis depuis votre portefeuille, jusqu'à une limite que vous définissez, et ce tant que vous ne la révoquez pas. Les approbations illimitées sont pratiques, mais elles donnent à ce contrat un droit de dépense de longue durée. Révoquer une approbation, via un outil comme revoke.cash, est une transaction distincte qui coûte du gas mais supprime ce droit. Traitez les approbations comme des clés et ne les confiez qu'aux contrats en lesquels vous avez confiance, uniquement le temps nécessaire.

Devrais-je utiliser un hardware wallet pour la DeFi ?

Un hardware wallet ajoute une solide couche de protection car la clé privée ne touche jamais votre ordinateur, mais à lui seul il ne vous empêche pas de signer une approbation malveillante. L'appareil affichera les détails de la transaction, ce qui est un vrai avantage, mais vous devez encore les lire. Associer un hardware wallet à la checklist ci-dessus, en particulier les étapes de simulation et de revue des approbations, est une configuration judicieuse pour les soldes importants.

Quel est le moyen le plus rapide de vérifier qu'une URL de dapp est authentique ?

Ne cliquez pas sur les liens provenant de résultats de recherche, des réseaux sociaux ou de messages privés. Tapez plutôt le domaine directement dans votre barre d'adresse, ou ouvrez-le depuis un favori que vous avez créé lors de votre première visite sur le site légitime. Vérifiez ensuite l'adresse du contrat sur un explorateur de blocs. La double vérification « URL plus adresse de contrat » permet d'écarter la grande majorité des tentatives de phishing en moins d'une minute.