Secure your Django project by validating incoming Twilio requests
In this guide we’ll cover how to secure your Django application by validating incoming requests to your Twilio webhooks are, in fact, from Twilio.
With a few lines of code we’ll write a custom decorator for our Django project that uses the Twilio Python SDK’s validator utility. We can then use that decorator on our Django views which accept Twilio webhooks to confirm that incoming requests genuinely originated from Twilio.
Let’s get started!
Create a custom decorator
The Twilio Python SDK includes a RequestValidator class we can use to validate incoming requests.
We could include our request validation code as part of our Django views, but this is a perfect opportunity to write a Python decorator. This way we can reuse our validation logic across all our views which accept incoming requests from Twilio.
To validate an incoming request genuinely originated from Twilio, we first need to create an instance of the RequestValidator class using our Twilio auth token. After that we call its validate method, passing in the request’s URL, payload, and the value of the request's X-TWILIO-SIGNATURE header.
That method will return True if the request is valid or False if it isn’t. Our decorator then either continues processing the view or returns a 403 HTTP response for inauthentic requests.
Use the decorator with our Twilio webhooks
Now we’re ready to apply our decorator to any view in our Django project that handles incoming requests from Twilio.
To use the decorator with an existing view, just put @validate_twilio_request above the view’s definition. In this sample application we use our decorator with two views: one that handles incoming phone calls and another that handles incoming text messages.
Note: If your Twilio webhook URLs start with https:// instead of http://, your request validator may fail locally when you use Ngrok or in production if your stack terminates SSL connections upstream from your app. This is because the request URL that your Django application sees does not match the URL Twilio used to reach your application.
To fix this for local development with Ngrok, use http:// for your webook instead of https://. To fix this in your production app, your decorator will need to reconstruct the request's original URL using request headers like X-Original-Host and X-Forwarded-Proto, if available.
Disable request validation during testing
If you write tests for your Django views those tests may fail for views where you use your Twilio request validation decorator. Any requests your test suite sends to those views will fail the decorator’s validation check.
To fix this problem we recommend adding an extra check in your decorator, like so, telling it to only reject incoming requests if your app is running in production.
What’s next?
Validating requests to your Twilio webhooks is a great first step for securing your Twilio application. We recommend reading over our full security documentation for more advice on protecting your app, and the Anti-Fraud Developer’s Guide in particular.
To learn more about securing your Django application in general, check out the official Django security docs.
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.
