Secure your Gin project by validating incoming Twilio requests
In this guide, you'll learn how to secure your Gin application by validating incoming requests to your Twilio webhooks are, in fact, from Twilio.
With a few lines of code, you’ll write a custom middleware for our Gin project that uses the Twilio Go SDK’s validator struct method. You can then apply that middleware to any route which accepts Twilio webhooks to confirm that incoming requests genuinely originated from Twilio.
Let’s get started!
Create and apply a custom middleware
The Twilio Go SDK includes a RequestValidator struct that you can use to validate incoming requests.
Building this into a middleware is a great way to reuse our validation logic across all routes which accept incoming requests from Twilio.
To validate an incoming request genuinely originated from Twilio, you first need to create an instance of the RequestValidator struct using our Twilio auth token. After that you call its Validate method, passing in the request’s URL, payload, and the value of the request's X-TWILIO-SIGNATURE header. Remember that the incoming request from a Twilio webhook is of type application/x-www-form-urlencoded, so you will need to create a map and populate it with all of the key/value pairs from the request in order for this to work.
The Validate method will return the boolean true if the request is valid or false if it isn’t. Based on this result, this middleware then either calls context.Next() to pass the request onto the next middleware or handler code, or returns a 403 HTTP response for inauthentic requests.
To apply this middleware, add it to the list of handlers for any route before any code that requires this validation.
Your request validator may fail locally when you use a ngrok tunnel, or in production if your app is behind a load balancer, proxy, etc. This is because the request URL that your Gin application sees does not match the URL Twilio used to reach your application.
To fix this for local development with ngrok, you may want to manually set the value of the url based on your tunnel's scheme and host. To fix this in your production app, your middleware will need to reconstruct the request's original URL using deployment environment variables and request headers like X-Forwarded-Proto, if available.
Disable request validation during testing
If you write tests for your Gin app, those tests may fail for routes where you use your Twilio request validation middleware. Any requests your test suite sends to those routes will fail the validation check.
To fix this problem, we recommend adding an extra check in your middleware, telling it to only reject invalid requests if your app is running outside of a test environment. Implementation details such as checking for Go Flags vs environment variables will very depending on your development stack, but the principle remains the same.
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.
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.
