You’ve just deployed your latest Twilio serverless service. Everything looks great—your code runs without a hitch, no errors in sight—but there’s a hidden problem you might not realize: your sensitive data could be exposed to the entire internet. Unless specified as protected or private via the file naming convention, Twilio’s serverless toolkit creates public assets and functions by default. Are you unknowingly sharing more than you intended?

In this post, we’ll explain Twilio serverless basics, compare common cloud misconfigurations, and introduce a Python-based tool to help you identify and mitigate these exposures. We’ll also highlight steps to prevent such issues in the future, including our submitted code changes to the Twilio Serverless Toolkit to better surface publicly exposed resources.

What is Twilio Serverless?

Twilio Serverless is a development framework that allows developers to build and deploy applications directly within the Twilio ecosystem. It simplifies backend infrastructure by enabling developers to host code and assets without requiring dedicated servers or external hosting platforms. There are multiple ways to configure and deploy these services, one being the Twilio Console and the other Twilio Serverless Toolkit.

Twilio Serverless Toolkit

The Twilio Serverless Toolkit is a command-line interface (CLI) tool that facilitates the deployment and management of Twilio Serverless applications. It’s this toolkit’s default behavior that makes assets and functions public unless explicitly configured otherwise. It is the toolkit’s default behavior that differs from the secure-by-default behavior seen in the Twilio Console.

Serverless Functions and Assets

• Functions: Custom JavaScript code that executes on demand, often in response to events like webhook calls or Twilio API triggers. Functions handle logic, process incoming data, and return responses.
• Assets: Static files such as configuration files, JSON files, or media that can be used by your functions or external systems.

Twilio Visibility Settings

• Public: Accessible to anyone on the internet without authentication.
• Private: Accessible only to other functions within your Twilio serverless service.
• Protected: Accessible on the Internet, but requires authenticating with an X-Twilio-Signature header which is generated using the Twilio Auth Token.

When a function or asset is deployed, Twilio generates a unique URL for it. The structure of these URLs ensures they are not trivially guessable, but public resources can still be accessed if the URL is exposed or leaked. We’ll explore how Twilio constructs these URLs and why this matters for security in the next section.

If an asset or function should not be public, the user needs to specify either ‘private’ or ‘protected’ in the filename. For example, a file named numbers.csv can be made private by renaming it to numbers.private.csv or protected by renaming it to numbers.protected.csv.

The Twilio Serverless Toolkit simplifies deployment by handling the process for you, but users unfamiliar with its naming convention may unintentionally expose assets and functions, introducing security risks if not properly managed.

How Twilio URLs Are Generated

Twilio assigns unique URLs to each function and asset deployed via Twilio Serverless. These URLs are structured using a combination of your service name, environment, and a unique identifier. Because Twilio does not use sequential or predictable patterns, URLs are not trivially guessable.

However, public URLs can still be a security risk if exposed through logs, shared links, or indexed online. Attackers often use automated tools to scan for exposed URLs, and once discovered, these endpoints can be exploited. Security should not rely on obscurity alone but on explicit visibility controls.

The Risks of Public Visibility

Twilio’s serverless toolkit simplifies deployments, but public visibility of functions and assets by default can lead to significant security risks. This is analogous to companies that accidentally exposed objects in AWS S3 buckets, which led to countless data breaches.

Examples of Potential Exposures

• Functions: One example of a function is to retrieve a customer's past call logs. If an attacker discovers the URL for the function, they will be able to access private call details.
• Assets: An example of an exposed asset is a JSON or CSV file containing customer phone numbers and metadata. If an attacker discovers the URL for the asset, they can access this private information.

Default public visibility increases the attack surface and risks unauthorized access to sensitive information or functionality. Developers must take proactive measures to audit and secure their configurations.

How Do I Know If I Am Vulnerable?

To address these challenges, we developed a Python-based tool leveraging the Twilio SDK. This tool is designed to help developers quickly identify security risks in their Twilio serverless environments.

This tool will perform a visibility audit. It lists all public functions and assets in your Twilio account. These results can also be exported to a CSV.

How Do I Know If My Code is Public?

To determine whether your code or assets are publicly accessible, review the visibility settings during deployment or use tools like the one introduced here. Publicly accessible resources will be flagged in the audit output, allowing you to take corrective action.

However, not all public assets are a security risk—files like static HTML, CSS, or images are often intended to be publicly accessible. The key is ensuring that only public resources are exposed while keeping sensitive files, such as call logs or customer data, private.

How Can We Prevent This in the Future?

The Twilio Serverless Toolkit now highlights all public assets upon deployment. This enhancement, introduced via a pull request by Relay Hawk, modifies the deployment output to flag publicly accessible resources. By showing developers potential exposure during the deploy process, this update encourages immediate corrective action.

Twilio Best Practices

1. Explicitly Set Visibility:

   • Configure functions and assets as private unless they need to be publicly accessible.

2. Audit Regularly:

   • Use tools and manual reviews to detect misconfigurations.

3. Rotate API Keys:

   • Replace outdated keys and enforce scoped permissions. Twilio now offers Restricted API keys to limit the damage should API keys be compromised.

4. Secure Webhooks:

   • Authenticate all webhooks.

Recommendations for Twilio

• Change the default visibility for files without a public suffix in the serverless toolkit to private or protected.
• Let teams enforce security policies by setting organization-wide defaults to make deployments private.

Conclusion

Twilio’s serverless toolkit is a powerful tool for developers, but its default behaviors and known risks can lead to unintended exposures. By using the provided Python-based tool and adopting best practices, you can proactively identify and mitigate these vulnerabilities.

For those working in dynamic development environments, remember to regularly review your configurations. Automating this process by integrating our tool/scanner script into your CI/CD pipeline ensures continuous security validation, catching misconfigurations before they reach production.

Download the tool today and take the first step toward securing your Twilio serverless environment.

Need a second set of eyes on your Twilio account’s security? Contact us and let's ensure your Twilio account is secure.