Dépensez des centaines de milliers pour faire développer un projet Web3 par une équipe externalisée : le projet arrive enfin difficilement en ligne, mais à cause d’une porte dérobée technique dissimulée par les développeurs, les actifs des utilisateurs sont volés et le projet s’effondre directement. De tels cas réels ne sont malheureusement pas rares dans l’industrie. Beaucoup de porteurs de projet pensent qu’obtenir le code source signifie une livraison complète du projet, mais ils négligent les risques liés aux permissions et aux portes dérobées. Au final, le projet péniblement mis en place disparaît en une nuit. En réalité, nous n’avons pas besoin de maîtriser ou de comprendre un code complexe : en se concentrant sur quatre points de contrôle essentiels, on peut éviter la grande majorité des risques techniques laissés intentionnellement par des tiers.

Premièrement, vérifiez strictement les permissions des contrats intelligents et retirez les droits d’administrateur, les droits super-utilisateur et les permissions de mise à niveau du contrat. Bon nombre d’équipes de développement écrivent les contrats en conservant par défaut des privilèges d’administrateur. Prenons un exemple réel : après la mise en ligne d’un projet RWA, les développeurs disposaient des droits d’administrateur du contrat ; ils ont alors directement appelé des fonctions d’arrière-plan pour transférer les actifs mis en jeu des utilisateurs dans le contrat, sans que le porteur du projet ait aucune capacité d’intervention. Une fois le contrat déployé, la première chose à faire est donc de confirmer que les permissions d’administrateur, les droits d’opérations super-utilisateur et les droits de mise à niveau via le proxy du contrat sont entièrement transférés ou supprimés. Ne laissez pas les plus hauts privilèges du contrat entre les mains de l’équipe de développement : éliminez dès la racine la possibilité de modification des règles en coulisses ou de transfert d’actifs.

Deuxièmement, contrôlez strictement l’ensemble des portefeuilles du projet : la clé privée et les droits de signature doivent être entièrement détenus par vos soins. Le projet implique généralement trois types de portefeuilles essentiels : le portefeuille de déploiement, le portefeuille du pool de fonds et le portefeuille de gestion multi-signatures. Certains projets, pour gagner du temps, laissent directement l’équipe de développement gérer les clés privées des portefeuilles. Il y a déjà eu un projet de jeu on-chain : le portefeuille de fonds était confié à l’équipe de développement ; après une période d’exploitation, les développeurs ont simplement empoché plusieurs dizaines de milliers de USDT du pool. Le projet n’a eu aucune voie de recours. Quelles que soient les qualités de votre interlocuteur, les clés privées et les droits de signature des portefeuilles de déploiement, du portefeuille de fonds et du portefeuille multi-signatures ne doivent absolument pas être confiés à l’équipe de développement. Toutes les opérations de signature doivent être réalisées par le projet lui-même ; ne déléguez pas à l’équipe de développement la gestion des points d’entrée permettant d’accéder aux actifs.

Troisièmement, effacez complètement les droits d’administration du serveur ; gardez les plus hauts privilèges entre vos mains. Beaucoup de DApp et de plateformes fonctionnent sur des serveurs fournis par l’équipe de développement. Certaines équipes externes laissent discrètement des comptes de connexion serveur et des accès à l’interface de base de données en arrière-plan. Même si le code source a déjà été livré, tant que l’autre partie conserve un accès aux serveurs, elle peut encore modifier les pages front-end, falsifier les données back-end et voler les informations liées aux utilisateurs. Au moment de la livraison du projet, veillez à modifier tous les comptes administrateurs les plus élevés pour le serveur, le back-end et la base de données, et à supprimer tous les comptes de connexion de l’équipe de développement, ainsi que les clés SSH et les permissions d’exploitation du back-end. Une fois terminé, connectez-vous et faites une vérification de contrôle de votre côté pour confirmer qu’aucun compte « porte dérobée » résiduel n’a été laissé.

Quatrièmement, vérifiez le code en ligne sur la chaîne, comparez-le à la source livrée et faites appel à un tiers pour un audit afin d’identifier les risques. Attention : il est très facile de tomber dans des pièges. Le code source fourni par le développement et le code réellement exécuté sur la chaîne ne sont pas forcément la même base. Certains équipes livrent des fichiers sources « propres », mais la version déployée sur la chaîne peut dissimuler furtivement des adresses noires spécifiques et des fonctions cachées permettant de transférer des actifs. Ne regarder que le code source livré n’a aucun sens : il faut comparer si le bytecode des contrats déjà déployés sur la chaîne correspond au résultat de la compilation du code source. La plupart des acteurs de projet ont du mal à réaliser ce travail ; il est recommandé de confier cette comparaison à une institution d’audit tierce, afin d’écarter les backdoors cachées et les adresses à très haut risque.

Il faut rappeler à tous les acteurs de projet : la livraison d’un projet ne signifie pas que tout s’arrête dès que vous avez récupéré le code source. Le code source n’est qu’un des éléments livrables. Quatre points doivent être intégralement vérifiés et contrôlés exclusivement par le projet : les permissions des smart contracts, les clés privées de tous les types de portefeuilles, les permissions du back-end sur la chaîne côté serveur, et la cohérence du code sur la chaîne. Ce n’est qu’en remplissant ces quatre critères, en les faisant vérifier entièrement et en les gardant sous votre contrôle, que la livraison est véritablement complète.

Dans l’industrie, de nombreuses tragédies ne viennent pas de vulnérabilités intrinsèques du contrat, mais d’accidents causés par le maintien de permissions par des humains. Beaucoup de projets, au début, se concentrent sur la mise en œuvre des fonctionnalités et ignorent les vérifications de sécurité lors des étapes de clôture de la livraison. Ce n’est qu’après le vol des actifs que vient le regret.

Les risques pour les actifs des projets Web3 sont extrêmement élevés : ne pariez pas sur la seule confiance en vous fiant à l’intégrité professionnelle de l’équipe de développement. Sur le plan procédural, récupérez toutes les permissions, et assurez-vous que la phase de vérification est correctement réalisée ; c’est ainsi que vous empêchez l’équipe de développement de manipuler le projet par la suite et que vous garantissez la limite de sécurité concernant la protection des actifs.