Skip to main content

How to Prevent SMS OTP Abuse & Fraud

1. Background​

When integrating SMS services, businesses often expose their registration OTP API to the public. This frequently results in malicious attacks that lead to financial loss and service interruption. Common attack patterns include:

  • Repeated OTP requests to the same phone number
  • Bulk automated API calls
  • No separation between registration OTP logic and session/login OTP logic

2. Solutions​

To minimize losses and ensure service stability, we recommend strengthening protection from the following aspects.

Provider-side restrictions can only offer limited protection. The most effective approach is to harden the client and server logic.

2.1 API & Flow Security Review​

  • [Mandatory] Does the OTP API require a server-side token validation?

    • Temporary token issued by the server
    • Token must only be generated through a valid business flow

  • Check whether the registration OTP flow is isolated and does not affect other services

  • Verify whether OTP requests can be triggered from outside your app (e.g., by constructing requests via packet capture tools)

  • Validate request origin and detect illegitimate sources

  • [Mandatory] Does the OTP request bind key client parameters? Examples:

    • App version
    • Device ID
    • Session token
    • Timestamp + signature

2.2 Rate-Limiting Review​

  • [Mandatory] Phone number-based rate limit (e.g., 1/min, 3/10min, 10/day)
  • [Mandatory] Device-based rate limit (e.g., max 10 OTP/day per device)
  • Optional: IP-based rate limit

2.3 CAPTCHA & Risk Control Review​

  • Do you require image/slider CAPTCHA for high-frequency or abnormal requests?

    • Without this, simple scripts can trigger brute-force requests easily.

  • [Mandatory] Have you integrated bot detection (e.g., hCaptcha, anti-fraud SDK)?

    • Without this, automation scripts can fully simulate the workflow.

  • Do you use device fingerprinting to identify emulators, crawlers, or unstable devices?

    • 90% of SMS abuse is triggered using emulators.

  • Add a 60-second cooldown timer on the UI before the next OTP request.

2.4 Phone Number Security Validation​

  • Do you validate phone numbers (country code, length, regex)?

  • Do you detect phone number types?

    • Mobile, landline, VoIP (VoIP numbers are highly abuse-prone)

  • Do you maintain a risk number database (blacklist)?

    • For example: disposable SMS platform numbers, common fraud area codes.

2.5 Request Source & Behavior Analysis​

  • Log the following for every OTP request: Device fingerprint, IP, session token, User-Agent, phone number → These are essential for identifying fraud patterns.

  • Multiple sends → multiple failures → auto-blacklist

  • Do you detect abnormal patterns, such as:

    • One device requesting OTPs for many different phone numbers
    • One phone number being requested excessively
    • Highly regular request timing (machine-generated behavior)

  • Do you have alerts for repeated OTP requests without successful registration?

  • During small-scale attacks (e.g., targeted SMS bombing), do you automatically escalate restrictions?

    • For example: enforce slider CAPTCHA or human verification.

2.6 Replay Prevention & Process Security​

  • Are OTP codes bound to a specific “scenario”?

    • Example: Registration OTP cannot be reused for password reset.

  • Do you protect against concurrent OTP triggers?

    • When a number sends two requests simultaneously, only one SMS should be delivered.