One time verification challenge

Complexity	Medium
Pros	Validates if the webhook consumer controls a destination before sending webhook notifications Can be easily combined with other webhook authentication controls
Caveats	Additional implementation complexity
Examples	Adobe Sign Airship Microsoft OneDrive Okta Smartsheet Twitter Zoom

While all providers implement authentication and authorization to set up webhooks, that doesn't confirm if the webhook consumer controls the code receiving webhook notifications.

To mitigate this risk, webhook providers like Twitter, Okta, and Microsoft OneDrive implement a verification/challenge request.

The challenge request is sent during setup and contains a random string that should be relayed back as part of the response:

GET https://listener.com/my-webhook?validationToken=randomString
Content-Length: 0


HTTP/1.1 200 OK
Content-Type: text/plain


randomString

Webhook notifications are not sent until the challenge response is successful.

Additional security concerns for webhook providers

Webhook integrations seem simple to secure at the surface. However, webhook URLs can be explored by malicious actors — acting as legitimate webhook consumers — to carry out Distributed Denial of Service (DDoS), Server Site Request Forgery (SSRF), and other attacks to the provider infrastructure.

The best practices for webhook providers provides guidelines for mitigating these risks in webhook communications.