API security in transit

All Twilio API traffic uses HTTPS with Transport Layer Security (TLS) 1.2 or later. TLS encryption prevents interception and tampering of data between your app and Twilio.

When you send an API request to Twilio, the process works in the following way:

1. Your app initiates an HTTPS connection to Twilio.
2. The request reaches the nearest Twilio edge location to minimize latency.
3. Twilio validates the request including authentication, authorization, rate limits.
4. Twilio forwards the request to carriers and destinations through the Twilio Super Network.
5. Responses follow the same encrypted path back to your app.

This infrastructure design protects your requests in transit while maintaining performance.

To secure communication, Twilio enforces modern cipher suites. Cipher suites are algorithms that determine how data is encrypted during HTTPS connections.

Twilio maintains an updated list of supported cipher suites. To prevent known vulnerabilities, Twilio removes older, deprecated ciphers.

If your app receives TLS handshake errors or connection failures when calling Twilio APIs, your client may be using outdated or unsupported cipher suites. This occurs under the following circumstances:

• Your app runs on an older operating system or runtime with limited cipher support
• Your TLS library is outdated and doesn't include modern cipher implementations
• Your firewall or proxy filters connections to unsupported cipher suites

1. Update your TLS library, operating system, or runtime to the latest version.
2. Verify your app uses a modern HTTP client or SDK.
3. Review your network infrastructure (proxies, firewalls, load balancers) to ensure they don't restrict modern ciphers.
4. Test in a non-production environment before deploying updates.
5. Check the Twilio changelog for any cipher suite changes that may affect your app.

While Twilio encrypts requests in transit and protects data on Twilio systems, you must secure the apps and environments that interact with Twilio APIs.

Implement these practices in your apps:

• Use HTTPS for all customer-controlled web app endpoints.
• Validate and sanitize all input before sending to Twilio.
• Never log sensitive data such as Auth Tokens, API keys, or customer personally identifiable information (PII).
• Restrict network and system access to code that can make Twilio API requests.
• Apply security patches for operating systems, frameworks, dependencies, and SDKs.
• Protect webhook endpoints with signature validation and rate limiting.
• Monitor for suspicious API activity and unusual access patterns.

Some Twilio customers replace standard Twilio API endpoint with Vanity URLs with custom subdomains like mycompany.twilio.com.

Follow these configuration and monitoring practices:

• Configure your app to trust only the certificate for your registered vanity domain.
• Set up your Domain Name System (DNS) with CNAME or A records pointing to Twilio infrastructure.
• Supplement vanity URLs with authentication and authorization for security.
• Monitor DNS records regularly for unauthorized changes (DNS hijacking).
• Monitor certificate changes and expiration to detect tampering or misconfiguration.
• Implement certificate pinning if certificate validation is part of your security policy.
• Turn on Domain Name System Security Extensions (DNSSEC) validation if your infrastructure supports it.

Avoid the following practices:

• Assuming attackers have no visibility into vanity URLs. Vanity URLs can be discovered.
• Substituting authentication or rate limiting with vanity URLs.
• Neglecting to validate certificates because traffic doesn't leave vanity URLs.
• Failing to monitor DNS or certificate changes.

Secure your API integrations:

• Secure authentication: OAuth 2.0, API keys, and credential protection
• Secrets management: Storing and protecting credentials
• Webhook security: Validating inbound webhook requests
• Defense-in-depth strategy: Multiple security layers
• Twilio Global Infrastructure: Learn about Twilio's edge network