Ensuring secure communication between your application and Twilio is essential. There are several layers of security and validation that you can build into your web application for handling Twilio webhooks - let's review each of these.
The first step you should take to secure your web application is to ensure that you are using HTTPS for your web application's endpoint. Twilio will not connect to an HTTPS URL with a self-signed certificate, so use a certificate from a provider such as Let's Encrypt.
Twilio can use the HTTP protocol for callbacks - for instance, if you are working on a development environment that does not have SSL certificates installed. On your Twilio project's Settings page in the Console, the SSL Certificate Validation setting enforces validation on webhooks.
Be aware Twilio strongly recommends against pinning certificates. This is an outdated practice as certificates can be rotated at any time.
Here is the list of supported TLS ciphers for callbacks.
Your web application should verify that Twilio is the service that sent a webhook before responding to that request. This is important for securing sensitive data, and to protect your application and servers from abuse.
Twilio will sign all inbound requests to your application with an X-Twilio-Signature
HTTP header. Twilio uses the parameters sent in the webhook (either GET
or POST
) and the exact URL your application supplied to Twilio to create this signature. The signature uses the HMAC-SHA1 hashing algorithm with your Twilio account's auth token as the secret key.
Your application can verify that this signature is correct using the server-side Twilio SDKs (see examples below). You will need your account's auth token, the value of the X-Twilio-Signature
HTTP header Twilio passed to you, the URL Twilio sent the webhook to and all parameters sent by Twilio.
The parameters included in webhook events vary by channel and event type and are subject to change in the future. Twilio will occasionally add new parameters without advance notice. When integrating with webhooks, your implementation must be able to accept and correctly run signature validation on an evolving set of parameters. We strongly recommend using the provided signature validation library from a Twilio SDK and not implementing your own signature validation.
When validating the signature on a WebSocket request, note that the header parameter name will be all lowercase: x-twilio-signature
.
1// Get twilio-node from twilio.com/docs/libraries/node2const client = require('twilio');34// Your Auth Token from twilio.com/console5const authToken = process.env.TWILIO_AUTH_TOKEN;67// Store Twilio's request URL (the url of your webhook) as a variable8const url = 'https://mycompany.com/myapp';910// Store the application/x-www-form-urlencoded parameters from Twilio's request as a variable11// In practice, this MUST include all received parameters, not a12// hardcoded list of parameters that you receive today. New parameters13// may be added without notice.14const params = {15CallSid: 'CA1234567890ABCDE',16Caller: '+12349013030',17Digits: '1234',18From: '+12349013030',19To: '+18005551212',20};2122// Store the X-Twilio-Signature header attached to the request as a variable23const twilioSignature = 'Np1nax6uFoY6qpfT5l9jWwJeit0=';2425// Check if the incoming signature is valid for your application URL and the incoming parameters26console.log(client.validateRequest(authToken, twilioSignature, url, params));
For more, including code samples and a description of how Twilio signs requests to your web application see this page on how to validate Twilio requests. The exact algorithm that Twilio uses to calculate the signature header (including whether or not the port number is used) is described in detail.
Once you've decided to add Twilio request validation to your application, you can follow one of our handy tutorials for your chosen language and web application framework. Do you use something we don't have on this list? Let us know, and we'll try and point you in the right direction.
Twilio uses a cloud architecture to provide services, and as such, does not have a fixed range of IP addresses that issue webhooks.
When designing your network architecture, you may wish to have one set of servers and a load balancer in a DMZ that receive webhook requests from Twilio, and then proxy those requests to your private network.
For more about Twilio and IP Addresses, please see this support Article: All About Twilio IP Addresses
Twilio supports HTTP Basic and Digest Authentication. This allows you to password-protect the TwiML URLs on your web server so that only you and Twilio can access them. You may provide a username and password via the following URL format.
https://username:password@www.myserver.com/my_secure_document
For more about how Twilio uses HTTP Authentication for webhook requests, please visit the Security documentation.