The receiver can't ask the sender to prove anything new
A webhook is an unsolicited inbound request — the receiving system registered a callback URL in advance and now has to decide, for each request that arrives at it, whether it genuinely came from the expected sender. Unlike a normal login flow, there's no opportunity to challenge the caller interactively or step up authentication mid-request; the authorization has to be verifiable from the request itself.
The common approach is a shared signing secret: the sender computes a signature over the payload using a secret established out of band, and the receiver recomputes it and compares. This authenticates the payload's origin and integrity without requiring a live back-and-forth, but it depends entirely on that shared secret staying confidential and on the receiver actually checking the signature rather than trusting the source IP or a fixed URL path.
Replay and endpoint exposure are the specific risks
Because the receiving endpoint is often a stable, guessable URL, and because a captured valid request can potentially be replayed, webhook verification typically needs a timestamp or nonce checked alongside the signature, not just the signature alone. Skipping that check leaves a system open to an old, legitimately-signed request being resent later to trigger the same action again.
The endpoint itself also deserves the same scrutiny as any other network-facing surface: rate limiting, strict content validation, and treating the payload as untrusted input until the signature check passes, not after.