Qu'est-ce qu'une attaque par rejeu dans la crypto ? Comment cela fonctionne et comment l'éviter (2026)

April 28, 2026 — By Tony Rabbit in Tutorials

Une attaque par rejeu se produit lorsqu'une transaction valide ou un message signé peut être réutilisé dans un autre contexte sans votre intention. Ce guide explique où les attaques par rejeu apparaissent dans la crypto, pourquoi elles sont importantes et comment les utilisateurs et les développeurs peuvent s'en défendre.

Une attaque par rejeu se produit lorsqu'une transaction crypto valide ou un message signé est utilisé à nouveau dans un second contexte que vous n'aviez pas l'intention d'approuver. La partie dangereuse est que la signature originale peut toujours sembler légitime. Le problème n'est pas que la signature était fausse. Le problème est qu'elle est restée réutilisable.

Le risque de rejeu appartient à la même famille que les erreurs de signature aveugle, le phishing par signature et les flux d'approbation non sécurisés, mais ce n'est pas la même chose. Une attaque par rejeu concerne spécifiquement une autorisation légitime qui est répétée là où elle ne devrait plus être valide.

Problème central

Une action valide se répète

Généralement lié à

Protection de contexte manquante

Meilleur état d'esprit

Ne jamais signer aveuglément

Comment fonctionne une attaque par rejeu

Le schéma de base est simple :

Un utilisateur signe une transaction ou un message qui semble normal.
Ce payload signé reste valide dans un autre environnement, chaîne, chemin de contrat ou flux de soumission répétée.
Un attaquant ou un système défaillant le réutilise.
L'utilisateur subit une seconde action qu'il n'avait jamais prévue.

Rejeu de transaction

Une diffusion valide sur un réseau ou un contexte est soumise à nouveau où la même signature passe toujours.

Rejeu de message

Un message signé sans séparation de domaine suffisante est réutilisé pour un chemin de demande différent.

Risque inter-environnements

Les applications, sidechains, forks et intégrations personnalisées sont là où une mauvaise hygiène de contexte devient coûteuse.

Où les attaques par rejeu apparaissent généralement

Contexte	Pourquoi le risque apparaît	À surveiller
Forks de chaîne	Une transaction valide d'un côté d'une scission peut également être valide de l'autre si les protections sont faibles.	Guidance des portefeuilles, procédures de scission et avis de protection contre le rejeu.
Messages signés	Un design de message lâche peut permettre une réutilisation au-delà de l'action prévue.	Séparation de domaine, nonces et invites lisibles par l'homme.
Applications inter-réseaux	Plus il y a de pièces mobiles, plus il est important que le lien de contexte soit strict.	ID de chaîne exact, adresse de contrat et objectif de la demande.
Flux de signature personnalisés	Des backends mal conçus peuvent recycler des payloads ou accepter des signatures périmées.	Fenêtres d'expiration et gestion des nonces.

Attaque par rejeu vs menaces de portefeuille à proximité

Menace	Astuce principale	Différence clé
Attaque par rejeu	Réutilise une action valide	La signature était réelle, mais elle est restée valide là où elle ne devrait pas.
Phishing par signature	Trompe l'utilisateur pour qu'il signe une mauvaise demande	La demande initiale elle-même est malveillante ou trompeuse.
Approbation non sécurisée	Laisse les permissions de dépense trop larges	Le risque est une autorisation continue, pas une réutilisation répétée de la même action.

Comment les utilisateurs réduisent le risque de rejeu

Utilisez des portefeuilles et des applications réputés. Des outils matures gèrent généralement mieux les ID de chaîne, les nonces et la séparation de domaine.
Lisez chaque demande de signature. Si l'invite est vague, illisible ou déconnectée de ce que vous faites, arrêtez-vous.
Évitez de signer aveuglément lorsque cela est possible. Moins vous voyez de contexte, plus les surprises de type rejeu peuvent se cacher dans le flux.
Soyez particulièrement prudent autour des nouvelles chaînes, forks et ponts non officiels. Ces environnements sont ceux où la confusion de contexte compte le plus.
Segmentez le risque avec des portefeuilles dédiés. Une structure de portefeuille propre limite le rayon d'explosion si quelque chose tourne mal.

Ce que les développeurs doivent bien faire

La résistance au rejeu n'est pas seulement un problème d'éducation des utilisateurs. C'est un problème de conception de protocole.

Liez les signatures à une chaîne ou un domaine spécifique
Utilisez des nonces pour que les anciennes signatures ne puissent pas être rejouées indéfiniment
Ajoutez des fenêtres d'expiration aux actions sensibles au temps
Affichez un contexte de signature clair et lisible par l'homme dans l'invite du portefeuille
Testez des cas particuliers étranges à travers les environnements au lieu de seulement le chemin heureux

Idées reçues courantes

Si la signature est réelle, elle doit être sûre. Faux. Une signature réelle peut toujours être mal réutilisée.
Les attaques par rejeu ne comptent que lors de scissions massives de chaînes. Faux. La conception des messages et l'expérience utilisateur multi-réseaux comptent également.
Les utilisateurs peuvent résoudre cela seuls. Faux. Une protection forte contre le rejeu nécessite une meilleure ingénierie en amont.

Conclusion

Une attaque par rejeu est l'un des exemples les plus clairs de l'importance du contexte de signature en crypto. Si une autorisation valide n'est pas étroitement liée à l'endroit, au moment et à la manière dont elle était censée être utilisée, elle peut voyager plus loin que l'utilisateur ne s'y attendait.

Pour les utilisateurs, la règle est simple : traitez chaque signature comme un véritable événement de permission, pas comme un pop-up inoffensif. Pour les développeurs, la règle est encore plus simple : ne laissez pas les signatures valides rester valides là où elles n'ont absolument pas besoin de l'être.