Webhook Security
Introduction to Webhook Security
Webhooks can be secured during setup, runtime, and with compensatory controls:
During Setup
Webhook providers implement security controls during webhook setup to reduce the risk of webhook exploration to obtain confidential data. All webhook services we researched provide authentication and authorization to set up webhooks in their Admin UIs and APIs. Some webhook providers implement an additional one time verification challenge to confirm that the webhook consumer controls the endpoint.
During Runtime
Webhook providers implement security controls on runtime to give consumers ways to validate if notifications are authentic, not tampered with, or replayed.
During our research, we found many different ways that providers provide security during runtime. We broke down each authentication and message security control with some examples, a summary table, and some diagrams:
- Shared Secrets, Basic Authentication, Bearer Tokens, and Verification tokens
- Hash-based Message Authentication Code (HMAC)
- Asymmetric Key Signatures
- JWTs, JWKs, and OAuth 2.0
- Mutual TLS Authentication (mTLS)
- Dataless Notifications and Thin Events
- Replay Prevention
Not sure which method a provider uses? The webhook directory lists the hash algorithm, encoding, and replay prevention for each one, and the glossary defines the terms used here.
Compensatory Controls
Webhook listeners can implement compensatory controls — such as IP restrictions and API callbacks to the webhook service — to increase the overall security of webhook communications. We will dive into compensatory controls under Best practices for webhook consumers.
Protecting the Provider
Webhook security runs both ways. Because consumers choose the destination URL, providers must keep their webhook system from being turned against their own infrastructure. See SSRF and Egress Security.