What Counts as a Webhook Replay Attack?
Webhook replay protection is the set of controls used to ensure that a webhook request is a fresh, legitimate delivery rather than a captured request being submitted again. A sender signs a payload, includes a timestamp, generates a unique delivery identifier, and transmits both values to a receiver. The receiver verifies the signature against the raw body, checks that the timestamp remains inside an acceptable time window, and records the delivery identifier so the same event cannot be processed twice. These controls address different problems: signatures establish authenticity, timestamps limit an attacker’s opportunity to reuse a request, and event IDs stop duplicate processing.
Also worth reading: What Should Webhook Delivery SLOs Be for Reliable B2B IP Registry Platforms? · How Do IP Rights Registry Software Platforms Work for Legal and Product Teams in 2026? · How Do IP SaaS Platforms Compare on Cost, Features, and Implementation Risk in 2026?
A replay is not necessarily malicious. Networks, proxies, load balancers, SDKs, and sender-side retry queues can produce repeated deliveries. For example, if a receiver returns a timeout after processing an event but before the acknowledgement reaches the sender, the sender may deliver the same event again within seconds. A well-designed receiver must therefore be idempotent even when replay detection has already rejected the duplicate. Replay protection should be treated as one layer in a broader delivery-security design, not as a substitute for signature verification, authorization, SSRF controls, or safe business-logic handling.
The relevant security boundary is usually the moment when the receiver accepts and processes the webhook, not the moment when a sender transmits it. Queueing a request does not by itself make it safe; the signature, age, and identifier need to remain associated with the event through processing. In a B2B intellectual-property rights or registry platform, this distinction matters because repeated calls can create duplicate matters, version histories, assignments, filings, invoices, notifications, or synchronization records. Correctness and auditability may matter as much as immediate loss prevention.
Which Replay Controls Should a Receiver Enforce?
The baseline control is HMAC-SHA256 verification over the exact raw request body, using a versioned webhook secret. Plain SHA-256 hashing of a payload does not authenticate the sender because anyone who can observe the payload can calculate the same hash; an HMAC additionally uses a secret key unavailable to the attacker. Several HMAC implementations also prepend the timestamp to the signed material, binding the body to its delivery time. Receivers should use a constant-time comparison for signatures and reject malformed, missing, or unsupported values rather than silently bypassing verification in test-like conditions.
Timestamp validation limits how long a captured signed request remains useful. A five-minute tolerance is a common starting point, but it is not universal: senders with substantial clock skew, long-lived batch jobs, or delayed queue processing may need a wider window. Widening the window to 24 hours merely to avoid occasional false rejections weakens replay protection considerably. A defensible default is to accept less than 300 seconds of clock skew when the provider’s delivery model allows it, monitor rejected requests, and adjust deliberately. The receiver should also compare its clock against a reliable time source because a machine with an incorrect clock can reject valid events or make age controls unreliable.
A unique event or delivery ID provides the final duplicate-processing barrier. The receiver should atomically insert that ID into a store with a uniqueness constraint, then associate the event with its processing outcome. An in-memory cache is useful for a single-instance service, but it loses state during a restart and does not coordinate multiple instances. A transactional database, Redis key with an appropriate expiry, or another shared store is usually more reliable. The retention period should exceed the sender’s maximum retry period; retaining an ID for only five minutes is inadequate if the provider can retry for three days. Exact replay rates vary by provider, so the retry contract is more useful than a universal expiry number.
How Do You Implement Replay Protection Safely?
Begin by preserving the raw request bytes exactly as received. Parse the JSON only after verification, and do not reserialize it before calculating the HMAC, because changes in whitespace, key order, escaping, or numeric representation can produce a different digest. Confirm that the body is not larger than the business endpoint can safely buffer, set an explicit timeout, and reject content types that are not supported. A signature check performed against a parsed-and-reformatted body may appear secure while accepting requests that would fail the sender’s specification.
Next, verify the event type and account or tenant context before doing work. A valid signature proves that the holder of a shared secret produced the request; it does not automatically prove that the payload is appropriate for the current endpoint, tenant, or operation. In a multi-tenant SaaS environment, map the incoming account identifier to a server-side record and ensure that the webhook endpoint is associated with that account. Do not trust a customer-supplied URL, arbitrary callback destination, or user-controlled redirect as though it were a trusted sender. If the architecture allows delivery to customer-owned URLs, SSRF checks and destination validation remain relevant even when the payload is signed.
After verification, record the event ID and process the event in a transaction or an idempotent workflow. If the ID already exists, return an appropriate success response when the prior attempt succeeded, or route the request to a controlled recovery path when processing previously failed. Do not repeatedly invoke an external filing, payment, rights-record, or registry operation merely because a duplicate arrived. Use a stable business key where available, such as provider plus external event ID, and keep an audit trail showing when the first acceptance occurred, how many duplicates were seen, and which processing result was recorded.
Finally, test both acceptance and rejection cases. Capture known requests, alter one byte, change the timestamp, reuse an ID, and submit a valid event twice. Confirm that the first request succeeds, the second is recognized, invalid signatures fail, and valid events outside the configured age window fail without crashing the receiver. Log security outcomes without recording the full secret or unnecessarily exposing sensitive legal or product data. The objective is not to eliminate every duplicate event; it is to ensure that each business effect occurs at most once while preserving a reliable audit history.
Replay Protection Versus Idempotency, Signatures, and SSRF Checks
These controls solve related but distinct problems. A signature authenticates a payload, a timestamp limits replayability, an event ID detects repetition, and an idempotency key prevents repeated business effects. Treating them as interchangeable produces brittle systems. For instance, a valid duplicate can pass HMAC verification because the sender generated both signatures correctly. Conversely, an idempotency check cannot determine whether a new request was forged by an attacker who knows an event ID. A system may need all four controls, depending on how it handles events and retries.
| Feature | HMAC signature verification | Timestamp validation and event-ID tracking | Idempotent business processing |
|---|---|---|---|
| Main purpose | Confirms authenticity and payload integrity | Limits freshness and detects repeated delivery | Prevents the same business action from taking effect twice |
| Typical technology | HMAC-SHA256 with a shared secret | Clock-window check plus unique event store | Database constraint, state record, or provider idempotency API |
| Main limitation | A stolen or exposed secret can be used to create valid messages | A wider time window or short ID retention weakens the barrier | Requires correct business keys and reliable state management |
| Common test | Change one payload byte and expect rejection | Reuse a valid request or event ID and expect one accepted effect | Submit the same operation twice and verify one durable result |
| Retention or tuning | Secret rotation and safe comparison | Often seconds for age checks; days for retry-related IDs | Based on the business object and audit requirements |
What Are the Common Failure Modes and How Can Teams Avoid Them?\nThe most frequent failure is verifying the body after JSON parsing or canonicalization. Another is accepting requests based only on a timestamp or event ID without verifying the signature. Some systems check replay state before authentication, allowing an attacker to fill storage with arbitrary event IDs; others log a secret or full legal payload, creating a secondary disclosure risk. Error responses also matter: returning a 200 response for an unverified event can cause the sender to stop retrying a request that was never processed, while returning a permanent failure for a transient storage outage can produce unnecessary retries and duplicate pressure.
Clock configuration is another common source of incident. Servers that are minutes or hours out of sync can reject valid deliveries, while systems with no clock discipline may incorrectly conclude that a timestamp is fresh. Duplicate stores frequently expire too soon. If the sender retries for 72 hours, a 15-minute event-ID cache may protect only the first wave of duplicates. Teams should document the maximum retry interval, define an ID retention period longer than that interval, and distinguish a duplicate from a new event that happens to contain a similar payload.
The implementation must also resist race conditions. Two instances receiving the same event at nearly the same time can both check that an ID is absent and then process it unless insertion is atomic. A database unique constraint, a conditional write, or a distributed claim is necessary. Locking an entire request while performing a slow external call can increase timeouts and encourage more retries, so the claim and the business operation need a deliberate relationship. In rights-management workflows, that operation might update a matter, create a registry event, or synchronize with a counsel-facing dashboard; each should have a stable key and an auditable state transition.
Finally, do not make production replay rules depend on a permissive development flag. Test endpoints, fixtures, and replay tools should be clearly separated, and a test exception should not silently weaken a production tenant. A useful operational review reviews rejection counts by reason, old but otherwise valid events, duplicate frequency, secret-rotation status, and the ratio of retries to first deliveries. A rise in duplicates can reveal a sender outage or an infrastructure problem even when no attack occurred. Replay protection should generate useful signals rather than becoming a black box that rejects requests without explanation.
When Should a B2B Team Act, and What Should It Cost?\n\nAct before enabling production webhooks for customer or registry integrations, especially when events can create intellectual-property records, trigger counsel notifications, change deadlines, or initiate paid operations. The minimum launch requirement is authenticated payloads, bounded timestamp validation, unique event IDs, atomic duplicate handling, and an audit trail. Teams that cannot maintain shared replay state should prefer a single serialized consumer or a managed event-processing service until they can add database-backed claims. They should not assume that a sender-side retry setting is sufficient because the sender cannot see all failures in the receiver’s downstream systems.
\nA small internal integration may cost little more than a few engineering days if it uses an existing database and a standard HMAC library. A multi-tenant product with high event volume needs operational work for secret management, monitoring, retention, rotation, incident response, and replay-safe workflows. Managed webhooks, queues, API gateways, and event stores may reduce implementation effort, but pricing depends on request volume, retention, regional processing, support, and compliance requirements; there is no honest single market price for “webhook replay protection.” Budget for monitoring and storage rather than treating the security check as a one-time code snippet. \nThe team should establish thresholds using real traffic. Track the percentage of deliveries that are duplicates, the percentage rejected for age, the rate of signature failures, and the number of processing races. A duplicate rate above zero is normal for at-least-once delivery, while a sudden increase from a baseline near zero deserves investigation. Review the configuration after major provider changes, traffic growth, clock incidents, or a suspected secret exposure. For high-value workflows, run a game day by replaying signed test events in a non-production environment and verify that only one durable effect occurs. The right response is often a measured control set, not an expensive platform purchase.
A Practical Security Standard for Registry and Rights Workflows
A practical standard begins with a written contract: the sender identifies its event, supplies an RFC 3339 timestamp, signs a defined representation of the body, and documents the maximum retry period. The receiver verifies the HMAC over the raw bytes, rejects unsupported algorithms, checks timestamp age, and atomically claims the event ID. The receiver then applies tenant authorization and idempotent processing, returning a deliberate acknowledgement for success, temporary failure, or permanent rejection. Every transition should be observable without exposing the shared secret.
The standard should be stricter when a webhook changes a legal deadline, ownership record, assignment, filing, invoice, or external submission. Those events may need a durable state machine, an explicit pending-to-completed transition, and a reconciliation process for uncertain downstream outcomes. If a network timeout occurs after an external registry accepted a request, the receiver should not infer failure or blindly resubmit; it should query or reconcile using a provider reference. Replay protection helps prevent accidental duplication, but it cannot resolve every distributed-systems ambiguity. Teams should state that limitation in their design rather than presenting a duplicate-ID check as complete exactly-once delivery.
The date context of September 2026 does not change the fundamentals. HMAC-SHA256, timestamp checks, unique IDs, and transactional idempotency remain practical controls, while newer webhook tooling can make testing and delivery inspection easier. For iprs.cloud-style B2B intellectual-property-rights and registry SaaS, the business consequence should determine the rigor: ordinary notifications may tolerate limited duplication, whereas changes to legal or commercial records require explicit auditability and reconciliation. Start with a short implementation window such as 300 seconds only when appropriate, retain replay records beyond the provider’s retry contract, rotate secrets, and review measurements monthly. That combination provides defensible protection without pretending that a single signature or timestamp eliminates every risk.