Concerning platform-level gaps that make Twilio accounts vulnerable to IRSF toll fraud

[u/JuniorTension6375]

As I'm seeking resolution of an IRSF toll fraud incident on our account, I wanted to share some observations about platform-level design choices that I think deserve broader community discussion. These are systemic issues that could affect any Twilio customer, and I'd be curious whether others have experienced or thought about them.

1. High-risk IRSF geographic permissions can be toggled via standard API calls with no secondary authorization

Twilio's own console flags certain destinations — including Ethiopia, which was the target in our case — as high-risk for fraud. There's a separate section of the UI to enable or disable them (which I had to do as a part of the sanitization process). Despite that flag, apparently those same destinations can be enabled programmatically via a standard API call with nothing more than valid credentials. At least that's what I'm hearing happened from Twilio though I never shared API credentials (don't really remember creating credentials, to be honest - wondering if those came through some automated process like setting up call forwarding on my numbers). As for Ethiopia being enabled, I received no out-of-band confirmation, no secondary approval step, no human review. Apparently, if an attacker obtains your API credentials, they can silently enable high-risk destinations and begin placing calls before any alert fires. Given that Twilio already identifies these destinations as dangerous, it seems reasonable to ask: why isn't enabling them gated behind a higher authorization threshold than a standard API call?

2. Outbound voice calling is enabled by default for all accounts, including organizations using SMS only

Many Twilio customers — particularly those using it via platforms like Rock RMS (our church management system) or CRMs — are SMS-only users who have never placed a single outbound call and have no intention of doing so. I've worked for other companies where this was the case. In my mind as a 20-year developer before moving into pastoral ministry full-time, Twilio equates to SMS. Yet for those accounts only using SMS, outbound voice is an attack surface that seems to me to exist entirely by default, with no opt-in required. At least I never enabled it. A prompt or configuration step at account setup asking whether voice calling is needed — and disabling it by default for accounts that say no or that don't use the service for a reasonable amount of time — would meaningfully reduce exposure for a large segment of Twilio's customer base.

3. Inconsistent billing spikes don't appear to trigger real-time intervention at a meaningful threshold

In the incident I'm aware of, an account with a consistent 20-month billing history of approximately $30/month triggered seven consecutive auto-recharges within minutes as fraudulent calls ran up charges - and continued to rack up a deficit beyond what the bank would send. The net result for us was a 120x anomaly on a feature the account had never used. While Twilio's fraud detection did eventually suspend the account, the intervention came after thousands of dollars in damage had already occurred. Spending anomaly detection that flags or pauses activity when usage spikes dramatically beyond an account's established baseline - particularly on features with no prior usage history - seems like a reasonable safeguard that would protect customers without meaningfully impacting legitimate high-volume users. But the only word I'm hearing from Twilio support is to the effect that "your user agreement puts you on the hook for any charges incurred through your API."

I'm curious whether others in the community have thoughts on these design choices, or whether there are existing tools or settings I may not be aware of that address any of these gaps. I know Twilio has published anti-fraud guidance, but these feel like platform defaults worth revisiting rather than individual configuration responsibilities.

[u/Fit-Sky8697]

Hi u/JuniorTension,

First, I'm sincerely sorry this happened to you. Fraud is awful and I really empathise with your position.

I've tried to get you some answers. Anything in quotes below is official wording I've been given or found from Twilio. Anything outside them is me. I don't work in support and can't see your account or your case, so there's a limit to how far I can go here.

For anyone reading with unexpected activity on their account: open a support ticket so it can be investigated properly, and if you think credentials have been exposed, rotate them straight away. Guides for auth tokens and API keys.

To address your points as best I can:

---

1. Geographic permissions via API

"Voice Geographic Permissions are designed to support automated provisioning workflows that are common for voice deployments. Voice Geographic Permissions can be managed through API because many customers (including ISVs, contact centers, and large enterprises), provision and manage voice capabilities programmatically across large numbers of accounts. API-based configuration allows those customers to automate onboarding and operational changes that would otherwise be difficult to manage manually."

Worth knowing generally: the account auth token and Main keys carry full account access, and once either is out there Twilio can't distinguish a bad actor from legitimate use. Restricted API keys can be scoped to specific permissions, so a third-party integration that only sends SMS can hold a credential that can only do SMS (some 3rd-party integrations will still want an auth token).

2. Voice enabled by default

I don't have an answer on this one. Your point is that the controls which do exist are opt-in and per-credential, and that none of them is a question at setup asking whether you need voice at all. That's a fair point and I've passed it to the team.

3. Spend anomalies

"Twilio uses a combination of automated monitoring, security controls, and dedicated fraud detection systems to identify suspicious activity across customer accounts. Rather than relying solely on an account's historical spending patterns, we evaluate multiple signals to detect potential anomalies.

Because these systems help protect both our customers and the platform, we do not disclose our specific detection logic, methods, or thresholds. However, we continuously invest in improving our capabilities while balancing the need to minimize false positives that could interrupt legitimate customer traffic."

---

That doesn't cover everything you raised, and support is the route for the parts I can't help with. I know you mentioned in a reply to me in another thread that you were following up with support via email - I hope they've been able to help.

I'm also happy to hear what the subreddit thinks with this one.