If your signup or login form can trigger an OTP, it can be abused to trigger OTP after OTP after OTP. This is called OTP pumping or toll fraud, and it's one of the more expensive ways an unprotected verification flow can hurt you: not a data breach, just a bill that grows for messages nobody asked for.
How the attack actually works
An attacker, usually a bot rather than a person, scripts repeated calls to your "send OTP" endpoint using a list of phone numbers. Those numbers are sometimes real but unrelated to any of your actual users, sometimes numbers the attacker has a financial stake in through a premium-rate or revenue-sharing arrangement with a telecom. Either way, every successful send costs you money and delivers zero real signups.
The reason this is possible at all: a "send OTP" endpoint is often the one part of a signup flow left unauthenticated by design, since the whole point is to verify someone who doesn't have an account yet. That openness is exactly what makes it a target.
What an attack looks like in your logs
- A sharp, sudden spike in OTP send volume with no matching spike in completed signups or logins
- Requests concentrated on a handful of country codes or number prefixes you don't normally see traffic from
- A high ratio of OTP sends to OTP verifications, since the attacker never has the real code to submit back
- The same small set of source IPs or devices generating a large share of requests
Any one of these alone can be a coincidence. Two or three together on the same day is worth investigating immediately, not at the end of the billing cycle.
Defenses that actually stop it
- Rate limit per phone number. A real user doesn't need ten OTPs in a minute. Cap requests per number with an increasing cooldown between attempts.
- Rate limit per IP and per device. Phone number limits alone don't stop an attacker cycling through a large number list from a small set of IPs.
- Add friction before the first send, not after. A CAPTCHA or basic bot check in front of the OTP request stops most scripted abuse before it costs you anything.
- Watch delivery rate, not just request rate. A burst of sends with an unusually low delivery rate is a stronger signal than volume alone.
- Block or challenge suspicious prefixes. If your product only serves a handful of countries, treat OTP requests to unrelated country codes as suspicious by default.
What Wevlix does on top of your own defenses
Wevlix includes built-in anti-pumping protection that applies limits per phone number, per IP, and per number prefix at the API level, so some of this protection is already active before you write a single rate-limiting rule of your own. It's not a substitute for application-level checks like CAPTCHA on your signup form, but it is a second layer that catches abuse patterns your own code might miss.
The practical takeaway
Treat your OTP endpoint like the unauthenticated, publicly reachable thing it has to be. Rate limit it at multiple levels, watch for delivery-rate anomalies rather than just volume, and don't wait for an invoice to be the first signal that something is wrong.
The Wevlix Team
