Quick answer: A webhook is when one system sends an automatic HTTP request to another when an event happens (for example a notification when a payment is received). Security wise webhooks carry two way risk: the receiving side must verify that the incoming request genuinely comes from the expected source (signature verification), and the sending side must prevent webhook URLs from being redirected to internal systems and turning into SSRF. The core defenses: signature verification, replay attack prevention and URL validation.

Why are webhooks a special risk?

Webhooks are the basis of system to system automation but are often neglected security wise. The problem is that an endpoint receiving a webhook may be exposed to the internet with weak authentication. An attacker can send fake requests to this endpoint and mislead the system, for example fabricating a fake "payment received" notification.

In the other direction, systems where users can enter a webhook URL (for example an integration setting) can turn into an SSRF attack when that URL is redirected to an internal address. So a webhook requires care both when receiving and when sending.

Webhook security layers

Layer Measure
Signature verification Signing and verifying each incoming webhook with a shared secret (HMAC)
Replay prevention Rejecting old requests with a timestamp and a one time id
Source validation Accepting only from a known sender IP or identity
SSRF prevention Blocking internal addresses in outgoing webhook URLs
TLS Always carrying webhook traffic encrypted
Business logic check Not blindly trusting webhook data, validating it

Why is signature verification critical?

The heart of webhook security is signature verification. The sending system signs each webhook with a shared secret key (usually HMAC). The receiving system verifies the signature with the same key. If the signature does not match, the request is rejected. This prevents the attacker from sending a fake webhook, because they cannot produce a valid signature without the secret key. A webhook endpoint that does not verify signatures is an open door where anyone on the internet can send fake notifications.

The KAOS and DSET approach

DSET performs security reviews of webhook endpoints: are incoming webhooks verified with signatures, are they open to replay attacks, do outgoing webhook URLs turn into SSRF. Our KAOS security engine evaluates webhook endpoints that do not verify signatures and URL inputs open to SSRF in an evidence based way. In our field experience the most common problem is the webhook endpoint not verifying the incoming request at all. Our goal is to show whether the webhook is open to fake requests.

Related reading: SSRF server-side request forgery defense, API security and OWASP API Top 10, API gateway security, HMAC and hash verification, hotel reservation and channel manager security, leaked API keys and secrets management.

Frequently asked questions

How do I verify a webhook? The most secure method is signature verification. The sending system signs each webhook with a shared secret key (HMAC) and carries the signature in a header. The receiving system recomputes the signature with the same key and compares. If it does not match, the request is rejected. A webhook endpoint that does not verify signatures is open to fake notifications.

What is a replay attack in a webhook? The attacker captures a valid, signed webhook and sends the same one repeatedly to trigger the operation multiple times, for example resending a "payment received" webhook. The measure is to add a timestamp and a one time id to the webhook and have the receiving side reject old or already processed requests.

How does a webhook URL turn into SSRF? In a system where users can enter a webhook URL, an attacker can redirect that URL to an internal address (for example a cloud metadata service or an internal API). When the system sends a request to that URL, it unknowingly accesses internal resources. The measure is to block internal and private addresses in outgoing webhook URLs.

Sources

For a security review of your webhook endpoints, you can talk to our team at Ankara Hacettepe Technopark. Contact DSET.