One time verification challenge
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.