Applications interact with each other using APIs and webhooks. APIs are used when applications need to create or manage resources in another service. Webhooks are used when applications need to receive notifications or updates from other services.

In this article, we are going to focus on security approaches when using webhooks. This is needed to ensure the webhook was sent from the real service and the payload was not tampered with. You should use one or more of these approaches to make sure the communication of services is safe.

IP allowed list

A very common solution to secure webhooks is to allow a list of IPs from the service that will send the webhook.
The advantage of this approach is that you can easily add this rule to your API gateway or firewall.
The drawback of this approach is when the service changes the IPs.

Authorization header

Another common approach is to use an Authorization header to verify if the webhook was sent from the real service.
The advantage of this approach is that you can easily implement it in your application code.
The drawback of this approach is that if you leak the authorization header you need to generate and modify your code. You can't also make sure the payload of the webhook wasn't tampered with.

HMAC (Hash-based Message Authentication Code)

HMAC combines a cryptographic hash function (like SHA-256) with a secret key to produce a unique hash value for a message. This hash value can then be used to verify the message's integrity and authenticity.

When using HMAC both applications share a secret that will be used to sign the webhook payload generating a unique hash that will be sent in a webhook request header. When receiving the webhook the application signs the received payload and validates the hash.

The advantage of this approach is that each payload will generate a unique hash, and modifying the payload will break the verification.
The drawback of this approach is that you need to share the same secret between this application and neither should leak it. The implementation of HMAC verification is also harder to implement.

Private and Public key

A not-so-common approach is to use a private-public key to sign webhook payloads. The Webhook sender has a private key that is used to sign all webhook payloads, the application that receives the webhook only validates the hash against the webhook sender's public key.
This approach ensures the message's integrity and authenticity.
The advantage of this approach is that the application that receives the webhook does not need to avoid leaking a private key, as it only needs to validate against a publicly known key.
The drawback of this approach is that it needs to be in application code instead of an API gateway or firewall.

Mutual TLS Authentication

Another option is to use mTLS for webhook authentication.
mTLS is the most complex and hard to scale as you need to keep manage all these certificates and expiration

In Conclusion

At Woov, we provide the four options above, except the mTLS.
We recommend using the Private Public key as the simplest and safest one.

Woovi is an innovative startup revolutionizing the payment landscape. With Woovi, shoppers can enjoy the freedom to pay however they prefer. Our cutting-edge platform provides instant payment solutions, empowering merchants to accept orders and enhance their customer experience seamlessly.

If you're interested in joining our team, we're hiring! Check out our job openings at Woovi Careers.

Photo by Bernard Hermant on Unsplash