Twilioの着信リクエストを検証してDjangoプロジェクトを安全にする

Andrew Baker

公開日: 2016-11-24

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.

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.

Confirm incoming requests to your Django views are genuine with this custom decorator.

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.

Apply a custom Twilio request validation decorator to a Django view used for Twilio webhooks.

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.

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.