Secrets management
To prevent credential compromise, you must keep your secrets secure. Twilio encrypts secrets at rest using Advanced Encryption Standard with 256-bit keys and Galois/Counter Mode (AES-256-GCM) cipher. Once Twilio issues credentials, you must protect them.
If you expose your Twilio credentials, an attacker might use them in one or more of the following ways:
- Sending unauthorized messages or making calls that impact your reputation or finances, such as toll fraud.
- Sending unauthorized messages or making calls that impact your reputation or finances, known. as Toll fraud
- Engaging in unauthorized messaging or voice activity.
- Abusing your account and consuming your resources.
- Accessing your account data without permission.
Store Twilio credentials in a dedicated secrets manager. Recommended solutions include:
- AWS Secrets Manager: For deployments hosted in AWS.
- Azure Key Vault: For deployments hosted in Microsoft Azure.
- Google Cloud Secret Manager: For deployments hosted in Google Cloud Platform.
- Enterprise secrets-management platform that your organization approved.
If you don't have a dedicated secrets manager, use server-side environment variables or an operating-system keychain. These provide acceptable minimum safeguards for development and limited deployments. These alternatives shouldn't replace a managed secrets solution for production workloads.
To protect your Twilio credentials throughout their lifecycle, follow these practices:
- Never hardcode credentials in source code, configuration committed to version control, or client-side JavaScript.
- Never commit credentials to a Git repository, even temporarily.
- Don't store secrets in plain-text documents, tickets, chat messages, or shared notes.
- Don't share secrets with coworkers or third parties through informal channels. Trusted people may still use compromised devices or websites.
- Limit access to secrets using least privilege and role-based access controls (RBAC).
- Separate production credentials from development and test credentials.
- Rotate credentials on a regular cadence and after personnel, vendor, environment, or access changes.
- Monitor access to secrets and investigate unexpected retrieval or use.
- Remove secrets from logs, error messages, crash reports, and support bundles.
- Revoke and replace credentials immediately if exposure is suspected.
These practices support a zero-trust architecture (ZTA):
- Grant access only to what needs to be accessed.
- Grant access only to the identities that need it.
- Grant access only as long as needed.
When you encounter one of these challenges, consider the offered solution:
| Challenge | Solution |
|---|---|
| Credentials for local development | Use short-lived credentials with restricted scope, stored in local environment variables or a keychain, and never committed to version control. |
| Rotating credentials without downtime | Implement dual credentials during transition. Create new credential, deploy, test, and then remove old credential. Automate where possible. |
| Third-party vendor API access | Use Restricted API Keys scoped to only the resources and permissions they need. Monitor their usage. |
| Credentials leaked in logs | Implement log redaction rules that prevent credentials from being stored. Identify sensitive fields with structured logging. |
Learn more about securing your Twilio integration:
- Secure authentication methods and best practices
- Incident response procedures for credential compromise
- Defense-in-depth strategy for layered security
To learn more about fraud-prevention, see Twilio's Quarterly Fraud Update.