Designing API Abuse Protection for Mobile Apps
Authentication is necessary, but it does not mean every authenticated action is legitimate.
A valid session can still automate OTP requests, replay sensitive operations, or distribute abuse across accounts and devices.
That is why API abuse protection needs multiple layers.
Protect the Action, Not Just the Endpoint
A useful model is:
Mobile Client
↓
Request Integrity
↓
Authentication
↓
Replay Protection
↓
Velocity + Rate Controls
↓
Business Risk
↓
Authorization
↓
Business Service
Each layer solves a different problem.
Authentication validates identity or session evidence. Authorization determines whether the actor can perform the operation.
Replay protection helps reject reused request material, while rate limits control resource consumption and velocity checks evaluate suspicious behavior across users, devices, networks, and time windows.
Replay and Retries Are Different
For sensitive operations:
timestamp
→ bounded freshness
nonce
→ replay resistance
idempotency
→ controlled legitimate retries
These controls are related, but they are not interchangeable.
A retry caused by a network timeout should not automatically execute the same financial operation twice.
Integrity Is a Signal
Mobile integrity mechanisms can provide evidence about the application or device environment.
That evidence should be validated by the backend and combined with other signals.
integrity
+ session
+ velocity
+ business context
+ authorization
→ server-side decision
A strong integrity signal does not prove an action is legitimate, and a weak signal does not independently prove fraud.
Rate Limiting Is Not Abuse Detection
A rule such as:
10 OTP requests / minute / IP
can help, but attackers can distribute activity.
A broader model may consider:
- phone number
- account
- device/install
- IP or network range
- beneficiary or target
- recent behavior
Rate limiting constrains usage.
Velocity analysis looks for patterns.
Device Signals Are Not Proof
An emulator or unusual environment can correlate with automation, but it does not automatically mean abuse.
Attackers can also automate physical devices.
Environment signals should therefore remain part of a wider risk decision.
Design for Failure
Abuse-control infrastructure can fail too.
If a velocity store becomes unavailable, allowing everything may remove an important control, while blocking everything may create an availability incident.
The degraded behavior should depend on the operation risk and remaining protections.
Residual Risk Remains
No integrity check, rate limiter, device signal, or behavioral rule eliminates API abuse.
The practical goal is layered protection:
- increase the cost of abuse
- restrict suspicious behavior proportionally
- preserve legitimate usage
- retain enough telemetry to explain decisions
The key architectural question is:
Does this action make sense for this identity, device, request, behavior, and business context?
That is stronger than simply asking whether the endpoint is authenticated.
Read the full article on Medium:
Top comments (0)