Why a copied request can still be dangerous
Many network requests carry authority: they may approve a payment, change an account setting, or submit a command. Encryption can hide a request while it travels, but it does not by itself stop an attacker who has captured a valid message from sending that same message again. The repeated request may still look authentic.
A nonce—short for “number used once”—adds freshness. The server issues or accepts a value tied to a particular request, and keeps track of whether that value has already been used. When the request arrives again with the same nonce, the server can recognize it as a duplicate rather than treat it as a new instruction.
The check has to be tied to the action
A nonce works only if the server checks it as part of the request and marks it used when carrying out the action. Otherwise, an attacker might change the request while reusing the number, or send two copies before either one is recorded. Systems therefore need to associate the nonce with the relevant user or session and make the “check and consume” step effectively happen once—even when requests arrive close together.
Servers also cannot remember every nonce forever. They typically accept values only within a limited time window and retain enough information to reject duplicates during that window. This balances replay protection against storage and cleanup costs.
The practical payoff is that a captured message can remain authentic yet become unusable after its first accepted use. That distinction matters: replay defense does not make a stolen credential harmless, but it can stop one valid request from being turned into the same action over and over.
