auditing-webhook-authenticity-and-callback-trustlisted

# Auditing webhook authenticity and callback trust: proving the caller and pinning the target A webhook is a trust boundary in two directions and both are easy to get wrong. Inbound, an internet caller posts a payload and the handler acts on it, provisioning access or crediting a balance, as if it came from the real sender; the only thing separating the real sender from anyone is a signature check that is often absent, compared unsafely, computed over the wrong bytes, or thrown away. Outbound, the same systems fetch a URL the caller supplied, a callback target or an import link, and a server-side request to an internal address reaches things the internet cannot. You find both by tracing the inbound request to the action it drives and the caller-supplied URL to the request it makes, and asking what proof or restriction stands between. ## When to use - A handler receives a webhook or callback and performs a state change based on its payload. - The application fetches a URL that a user registered or supplied, for a callback, import, preview, or discovery. - You want to know whether an unauthenticated caller can forge an event or steer a server-side request inward. ## Scope check Send forged events or callback URLs only to systems you own or are authorized to test, and prove internal reach only against infrastructure in scope. A working webhook forgery or a server-side request to internal services can move money or expose credentials, so coordinate. If you can't name the aut