Replay Protection

Cybersecurity / 20 Sep 2026 / 6 min read

Webhook HMAC Signatures Need Replay Controls

Webhook HMAC Signatures Need Replay Controls A webhook receiver often needs to decide whether an HTTP request came from a configured sender and whether the payload changed in transit. A keyed message authentication code can support that decision when both sides share a secret and compute the tag over the same bytes. That property does not make a captured request single-use. If an attacker records a valid request and submits the same authenticated material again, the tag can remain valid. Replay resistance therefore has to be part of the webhook protocol around the MAC, not an assumption attached to the MAC itself.

Cybersecurity Webhooks

Cybersecurity / 16 Sep 2026 / 6 min read

TLS Early Data Trades Handshake Latency for Replay Exposure

TLS Early Data Trades Handshake Latency for Replay Exposure A returning client can possess enough state from a prior TLS 1.3 connection to send application data alongside its first handshake flight. That removes a round-trip from the critical path for eligible traffic, but it also changes a security property that applications often treat as implicit: encrypted transport no longer means that a request can appear only once across connections. TLS 1.3 early data, commonly called 0-RTT, is protected using keys derived from a pre-shared key associated with an earlier session or an externally provisioned PSK. The server has not yet contributed fresh handshake state when those bytes are transmitted. As a result, early data has weaker replay properties than ordinary application data sent after the handshake.

Cybersecurity TLS

Cybersecurity / 10 Sep 2026 / 10 min read

Reject Replayed Sensitive Requests with Freshness and Uniqueness

A request can be authentic and still be unsafe to execute twice. Suppose a service accepts a correctly authenticated instruction to change a payout destination, approve a privileged action, or trigger another sensitive operation. If someone can capture that valid request and submit the same authenticated message again, checking its credentials or signature a second time may produce the same answer: the request is genuine. The server still needs to decide whether it is current and whether it has already been used.

Cybersecurity Authentication

Cybersecurity / 09 Sep 2026 / 10 min read

Make Sensitive Requests Replay-Resistant

A server can correctly prove that a request came from a trusted client and still process it more times than intended. If an authenticated request says “approve this payout” or “change this recovery address,” accepting the same valid request twice can create a security problem even though neither copy was forged. This is a replay problem. A replay happens when a previously valid message is presented again and the receiver cannot tell that its authority has already been used, or that the message is too old to trust.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 10 min read

Make Sensitive Operations Safe to Retry

A client sends a request to create a refund. The server completes the refund, but the response is lost when the connection closes. The client cannot tell whether the operation succeeded, so it retries. If the server treats the retry as a new operation, one uncertain network failure can become two refunds. The same pattern appears in credit transfers, invitation acceptance, provisioning, job submission, and other state-changing actions where repeating an effect has security or financial consequences.

Cybersecurity Secure Coding