Member-only story
Best Practice to Secure your WebHooks
Verification Token, Signature (HMAC), Thin Payload, Mutual TLS, Best Practices.
WebHooks is a URL prepared by the application developer (client) to receive information from the API Provider (server) without polling. For example, Github sends a POST request to the developer’s URL to inform a new pull request is opened.
Making WebHooks secure is different from making web APIs secure. It is because WebHooks is a URL that’s publicly accessible on the internet. Therefore, whenever there is a request that hits the URL, it is important to ensure that the request truly came from the expected sender. Without such verification, an attacker can fake a request sent to the WebHooks URL. Currently, there are no gold standard way to secure WebHooks, however, here are some of the common solutions deployed by both the API Provider as well as the client.
Verification Token
Verification token acts like a shared secret between the client and the server. The token is created when we register a new WebHooks. This method is used by Zoom, where every client is assigned a different verification token.
Once a verification token is set and the WebHooks is registered, every request that’s dispatched to the client’s URL will include the token. It is the client’s job to verify every token that come from requests. If they match, request is accepted. Otherwise, client may ignore the requests. This way, the client can verify that the sender of the request coming in is truly the expected server.
The advantage of this method is that it is simple to implement. However, the security is limited, as the token is sent in plain text on every request. If the token is leaked, the attacker can fake a WebHooks request and pretend to be the expected server.
Request Signing & WebHooks Signatures
Signatures is another common solution selected to secure WebHooks. The procedure and its order is as shown in the Figure:
- The server / API provider will…
