Authentication

Some people are concerned about non-authorized users calling their webhook endpoints and are looking at ways to try and lock them down to protect them.

The first thing to consider is that most of the time, the presence of any webhook server and the exact paths needed to make it do something are unlikely to be available to any casual hackers even if the https port is visible from a port scan. In order to avoid problems with casual attackers calling your webhook therefore, you should ensure that a path is always used in your webhook endpoint e.g. https://www.example.com/webhooks/surveycompleted Since webhooks must be invoked over https, this information is not exposed to anyone else.

The use of SNI with https also requires any attacker to know the URL name, not just the IP address of your webhook server so configure this if you can. In most cases, you should not have a PTR record for the IP address, which would permit the server name to be looked up, although again, you need to question what an attacker might be trying to achieve.

As a more secure alternative, if possible, you can simply use a long randomly generated string as part of the path. It does not need to be particularly securely generated since its length will ensure it cannot be guessed. For example, an online site might generate you a 32 character password (with URL friendly characters) like https://www.example.com/webhooks/surveycompleted/SLbM1T7jQ6GktshiXvlZ9Xnbd29EBV0y which could be part of the path or passed as part of the query e.g. https://www.example.com/webhooks/surveycompleted?auth=SLbM1T7jQ6GktshiXvlZ9Xnbd29EBV0y This then needs verification on your webhook server - just a simple string check will suffice - and then the request accepted if it does match. This will need to be included in the webhook endpoint box when adding a webhook into your SmartSurvey account.

We do not offer the list of IP addresses that webhooks are sent from for the simple reason that they are sent from cloud services whose IP addresses can change at short notice and this is therefore not suitable for authentication, you should use the random string/pre-shared-key technique instead.