Verify Publishing Webhook Signatures on Workers

Agree on the signed message

A signature verifier is only correct when sender and receiver agree on exactly what is signed. Document the algorithm, encoding, header format, signed components, and key identifier. Cloudflare Workers provides Web Crypto functionality that can support a suitable verification implementation. Follow the actual provider's specification rather than copying an unrelated webhook example. For a hypothetical analytics product accepting article deliveries, the signed material might include a timestamp and raw body, but that is a design choice to define explicitly rather than a universal webhook format.

Preserve the bytes needed for verification

Read the request in a way that preserves the original signed representation. Parsing JSON and then serializing it again can change whitespace or property order, producing different bytes even when the data has the same meaning. Verify before using the content to update records or trigger publishing jobs. Reject malformed signature metadata with a controlled response. Keep request limits appropriate for expected articles and media references. An integration should not accept arbitrarily large bodies merely because the sender normally sends small drafts.

Handle secrets as infrastructure

Keep verification secrets on the server using a proper secret mechanism. Cloudflare Workers secrets can hold deployment-level values; a multi-customer service needs an additional plan for independently managed tenant credentials. Support rotation by defining how a key identifier selects the permitted secret and how long an overlap lasts. Do not silently accept any historical secret forever. The analytics product may rotate one customer's connection without disrupting everyone else. Avoid logging the secret, authorization headers, or a complete private article when verification fails.

Add replay and destination checks

A valid signature establishes authenticity under the chosen scheme; it does not by itself establish that an event is new or intended for the current site. Define a permitted timestamp window where the protocol includes timestamps, and track processed event identities. Verify the tenant and destination before applying changes. An old signed event should not roll a newer article back accidentally. If delivery delays are possible, design the freshness policy with the retry system so normal recovery does not become impossible. Record the reason for rejection without revealing secret-dependent details.

Test both sides of the boundary

Include tests for a valid request, modified body, missing signature, wrong secret, unsupported key identifier, duplicate event, stale timestamp, and wrong destination. Confirm that none of the rejected requests create drafts or queue publication work. Test rotation with the intended overlap and retirement behavior. In the analytics example, a changed headline should invalidate the signature even if the remainder of the article is untouched. A useful production signal is accepted and rejected events by safe reason category. Verification is complete only when unauthorized data cannot cross into the trusted publishing workflow.

Keep a small set of known signed test requests that both sender and receiver can verify. These fixtures help identify encoding differences during implementation without requiring live customer secrets or production article content for debugging.