Condition de concurrence des autorisations ERC-20

Un dépensier ERC-20 peut utiliser une ancienne allowance avant la confirmation de l'autorisation qui la remplace, puis utiliser la nouvelle. Découvrez le fonctionnement de cette condition de concurrence et comment modifier ou révoquer des autorisations de façon plus sûre.

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

La condition de concurrence des autorisations ERC-20 peut se produire lorsqu’un propriétaire remplace une allowance non nulle par une autre en appelant approve(spender, newAmount). Un dépensier peut repérer le changement en attente, dépenser d’abord l’ancienne allowance avec transferFrom, puis utiliser la nouvelle allowance après sa confirmation.

La spécification ERC-20 recommande donc aux interfaces client de ramener d’abord l’allowance à 0 avant de définir une nouvelle valeur pour le même dépensier. Chaque transaction doit être confirmée dans l’ordre. Lorsqu’un token les prend en charge, les appels atomiques increaseAllowance ou decreaseAllowance évitent de remplacer directement une allowance non nulle.

L'ID de la chaîne et la vérification du contrat correspondent à l'application prévueLa fonction, le dépensier, le jeton, le montant, le nombre occasionnel et la date limite sont décodésL'allocation existante et la sémantique de remplacement ont été vérifiéesLes changements de solde et d’approbation ont été simulésDes appels, des délégués ou des transferts de valeur inattendus provoquent un rejet

0 / 5

0 articles examinés; 5 points toujours non résolus

La réalisation de cet examen ne prouve pas qu'un actif, une transaction ou un système est sûr.

Fonctionnement

ERC-20 définit approve comme un écrasement : un appel réussi à approve(spender, amount) fixe l’allowance du dépensier à amount. Par ailleurs, transferFrom(owner, recipient, amount) permet à ce dépensier de transférer les tokens du propriétaire et réduit normalement l’allowance restante. Les transactions en attente ne réservent aucun ordre d’exécution ; un dépensier peut donc soumettre un transfert qui s’exécute avant la modification de l’autorisation par le propriétaire.

La transition risquée est N -> M, avec à la fois N > 0 et M > 0. Si le dépensier consomme N avant l’exécution de l’autorisation de remplacement, l’autorisation ultérieure crée une nouvelle allowance de M. Le maximum dépensé au cours de cette séquence peut donc atteindre N + M, sous réserve du solde de tokens du propriétaire et de l’implémentation du token.

Exemple

Alice a autorisé un protocole à dépenser 100 tokens. Elle soumet approve(protocol, 50) pour ramener l’allowance restante à 50. Avant la confirmation de cette transaction, le dépensier du protocole soumet transferFrom(Alice, recipient, 100) et le fait exécuter en premier. L’autorisation d’Alice fixe ensuite l’allowance à 50, que le dépensier peut utiliser dans un autre transfert. Les deux transferts totalisent 150 tokens.

Une procédure de remplacement plus sûre consiste à soumettre approve(protocol, 0), à attendre la confirmation, à vérifier l’allowance et le solde obtenus, puis seulement à soumettre approve(protocol, 50) si la nouvelle autorisation reste appropriée. Si le dépensier utilise l’ancienne allowance avant la confirmation de la mise à zéro, Alice peut constater le changement de solde et s’arrêter avant d’accorder les nouveaux 50.

Risques

Ramener l’allowance à 0 n’annule pas une dépense déjà exécutée et n’empêche pas l’utilisation de l’ancienne allowance avant la confirmation de la mise à zéro.
Envoyer ensemble la mise à zéro et l’autorisation de remplacement, sans attendre la première confirmation, réintroduit un risque lié à l’ordre d’exécution.
increaseAllowance et decreaseAllowance ne font pas partie de la norme ERC-20 de base ; utilisez-les uniquement lorsque le contrat vérifié du token les prend en charge.
Une allowance illimitée peut exposer l’intégralité du solde de tokens du propriétaire tant qu’elle reste active. Vérifiez le réseau, le contrat du token, le dépensier et le montant avant de signer.
Certains tokens ont un comportement d’autorisation non standard. Lisez la simulation du portefeuille et les calldata de la transaction, puis vérifiez l’allowance on-chain après chaque étape.

Idées reçues courantes

« La dernière transaction d’autorisation remplace immédiatement l’ancienne. » Elle ne modifie l’état que lors de son exécution on-chain.
« Réduire une allowance plafonne toutes les dépenses futures au nouveau montant. » Un dépensier peut utiliser l’ancienne allowance avant l’exécution du changement.
« La mise à zéro en premier garantit qu’aucun autre token ne peut sortir. » L’ancienne allowance reste utilisable jusqu’à la confirmation de la mise à zéro.
« Tous les ERC-20 possèdent increaseAllowance et decreaseAllowance. » Ce sont des extensions facultatives, et non des exigences d’ERC-20.
« Révoquer la connexion au site révoque l’autorisation du token. » L’état de connexion du portefeuille et l’allowance on-chain du contrat du token sont distincts.

Sujets connexes

Sources

ERC-20: Token Standard - Ethereum Improvement Proposals (consulté le : 2026-08-20)
ERC20 | OpenZeppelin Docs - OpenZeppelin (consulté le : 2026-08-20)