Secure your Servlet app by validating incoming Twilio requests
In this guide we’ll cover how to secure your Servlet 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 filter for our Servlet app that uses the Twilio Java SDK’s validator utility. This filter will then be invoked on the relevant paths that accept Twilio webhooks to confirm that incoming requests genuinely originated from Twilio.
Let’s get started!
Create a custom filter
The Twilio Java SDK includes a RequestValidator class we can use to validate incoming requests.
We could include our request validation code as part of our Servlet, but this is a perfect opportunity to write a Java filter. This way we can reuse our validation logic across all our Servlets which accept incoming requests from Twilio.
The doFilter method will be executed before our Servlet, so it’s here where we will validate that the request originated genuinely from Twilio, and prevent it from reaching our Servlet if it didn’t.
First we gather the relevant request metadata (URL, query string and X-TWILIO-SIGNATURE header) and the POST parameters. We then pass this data onto the validate method of RequestValidator, which will return whether the validation was successful or not.
If the validation turns out successful, we continue executing other filters and eventually our Servlet. If it is unsuccessful, we stop the request and send a 403 - Forbidden response to the requester, in this case Twilio.
Use the filter with our Twilio webhooks
Now we’re ready to apply our filter to any path in our Servlet application that handles incoming requests from Twilio.
To use the filter just add <filter> and <filter-mapping> sections to your web.xml. No changes are needed in the actual Servlets.
In the <filter> section we give a name to be used within your web.xml. In this case requestValidatorFilter. We also point to the filter class using its fully qualified name.
In the <filter-mapping> section, we configure what paths in our container will use TwilioRequestFilter when receiving a request. It uses URL patterns to select those paths, and you can have multiple <url-pattern> elements in this section. Since we want to apply the filter to both Servlets, we use their common root path.
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 Servlet 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 filter 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 Servlets those tests may fail where you use your Twilio request validation filter. Any requests your test suite sends to those Servlets will fail the filter’s validation check.
To fix this problem we recommend adding an extra check in your filter, 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 Servlet application in general, check out the security considerations page in the official Oracle 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.
