Academy/Authentication/OTP Flooding
High severityAuthentication

OTP Flooding

An attacker triggers dozens or hundreds of OTP (one-time password) SMS messages to a victim's phone number. The goal is either to find a valid OTP by getting the user to accidentally confirm one, to overwhelm the victim's phone making it unusable, or to bury a real OTP request inside noise.

Think of it this way

Imagine someone spamming your doorbell 50 times in a row. By the time the real delivery arrives, you are so frustrated that you open the door without looking who it is. OTP flooding works the same way — the attacker drowns the real verification request in a flood of fake ones.

How it works

The attacker exploits your 'Send OTP' or 'Forgot Password' API endpoint, which is typically publicly accessible and requires only a phone number. They script rapid calls with the victim's number. Each call costs you money (SMS fees) and delivers an SMS to the victim. The attacker then calls the victim pretending to be customer support, asking them to read back the 'verification code' they just received — which is actually an OTP the attacker triggered to gain access.

Real-world scenarios

Scenario 1

Social engineering + OTP flood

An attacker floods a victim with OTP SMS messages, then calls pretending to be the bank's fraud team. They say 'we detected suspicious activity, please confirm the code we just sent'. The victim reads the OTP, the attacker logs in.

Scenario 2

SMS bill inflation attack

A competitor or malicious actor sends 50,000 OTP requests to random numbers using your API. This generates a massive SMS bill and causes your SMS provider to temporarily suspend your account due to volume anomalies.

Scenario 3

OTP bypass attempt

An attacker triggers 10 OTPs in quick succession and tries all 10 codes at the verification endpoint before any expire — hoping one is accepted. Combined with brute force on the 6-digit code, this can succeed if there is no lockout.

How Anomira detects this

Anomira detects when the same phone number or IP address triggers an abnormal number of OTP generation events in a short window. It also flags when OTP generation spikes across many different phone numbers from a single IP, suggesting a mass-flooding campaign.

What to do

  • Rate limit your OTP endpoint: maximum 3 OTP sends per phone number per 10 minutes.
  • Add CAPTCHA or proof-of-work to the OTP request endpoint.
  • Implement OTP expiry of no more than 5 minutes and single-use invalidation.
  • Alert users if they receive an OTP they did not request, and offer a 'this was not me' link.
  • Block IPs in Anomira that are flooding your OTP endpoint.

Related attacks

See this attack in your live API traffic

Anomira detects otp flooding automatically — no configuration needed.