Webhook Security

One time verification challenge

  • Medium
  • Validates if the webhook consumer controls a destination before sending webhook notifications
  • Can be easily combined with other webhook authentication controls
  • Additional implementation complexity

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


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.