Introduction
Apps can communicate with each other in one of two ways → Polling or through WebHooks. WebHooks are automated messages sent by an app when something happens. They have a payload and are sent to a unique URL (or phone number) that belongs to the app being communicated with. This is faster than polling and requires less effort to develop.
The consumer of the information provided via a WebHook must tell the originating app, the address of the WebHook, where the data will be received. The simplest way to do so is through an HTTP request, preferably a POST request.
WebHooks typically connect two applications. They are similar to APIs but are much simpler.
Security Issues in WebHooks
- Man in the Middle against HTTP data sent by WebHooks → Must always use TLS for exchange of any public data
- Forgery of WebHook requests → Verification in form of a hash passed in a header such as
X-<vendor>-hmac-SHA256must be added to prevent this type of attack - Lack of authentication → Can be fixed by adding a basic authentication header with a client generated secret over TLS
- Replay attacks → This can be prevented by ensuring idempotency of endpoints or by adding timestamped signatures for the
hmac
Security Solutions captured in tabular form is as follows →
Table
| Threat | Solution |
|---|---|
| Payload Exposure | HTTPS WebHook URLs with SSL Encryption |
| Attack from unknown WebHook sources | Authentication token, IP whitelists for WebHook source |
| WebHook interception and redirection | Client verification using Mutual TLS |
| WebHook payload corruption | Message verification using HMAC signatures |
| Replay attacks | Timestamped messages |