...
Method | Description | Pros | Cons |
|---|---|---|---|
IP Whitelisting | Denies any request from an IP address that is not included in the IP whitelist. | Arguably the most secure | In today's cloud and serverless world, the amount of IP addresses and ranges can be endless. For example, Slack webhooks originate from AWS which has 1000s of possible IP addresses. |
Tokens | Passing some token (generally as a query param) in webhook urls. The reverse proxy then denies any request without this token. | Not restricted by IP | Token is visible in webhook urls |
Resource Matching | Ensuring that your reverse proxy only forwards requests for certain resources. For example /flexdeploy/webhooks/v2. This denies any request to the base flexdeploy application through the proxy but allows requests to the webhook resource. | Not restricted by IP Not maintaining a token | Allows all requests through the proxy as long as the resource is /flexdeploy/webhooks/v2 Puts more ownership on the Provider Match script to determine malicious intent. |
Hmac Encryption | A number of webhook providers (GitHub, Slack, Bitbucket Server) will encrypt the payload with a secret that you provide and pass the encrypted string as a header. When receiving the request you then encrypt the payload with the same secret and validate it matches the header that was passed from the provider. This is a more secure version of the Token approach above but not offered by all providers. | Second most secure behind IP whitelisting | Not offered by all providers |
...