Put limits on every public endpoint that triggers a paid action. Cap requests per phone number, account, device and network, add a global ceiling and a spending limit at the provider, and alert on spikes. A mobile app's sign up and password reset calls are the usual targets.
The scenario
OWASP's API Security Top 10 describes unrestricted resource consumption with a concrete case. A social network built a forgot password flow that sends a one time code by SMS. When a user taps the button, the app calls the backend, and the backend calls a third party service that delivers the text. The third party charges for each message.
An attacker wrote a script that called the first endpoint tens of thousands of times. The backend dutifully asked the SMS provider to send tens of thousands of messages, and the company lost a large sum of money in a few minutes.
Nothing was hacked in the usual sense. The endpoint did what it was built to do, without any limit on how often.
Which endpoints are at risk
| Endpoint | Paid action behind it |
|---|---|
| Request a sign in or reset code | SMS or voice call |
| Invite a friend or colleague | Email or SMS |
| Resend verification | Email or SMS |
| Identity or biometric check | Per check vendor fee |
| File or image processing | Compute and storage |
| Export or report generation | Compute and database load |
OWASP lists the limits an API should have: execution timeouts, memory limits, upload size limits, the number of operations per request such as GraphQL batching, the number of records per page, and a spending limit for third party providers.
Steps to take
- List every endpoint that triggers a cost or heavy work. Mobile apps often call these before the user is signed in, so there is no user identity to limit by.
- Apply limits at several levels, since an attacker can rotate any single key. Count per phone number or email address, per account, per device or install where you have a reliable signal, per network address with care for shared carrier networks, and add a global ceiling across all callers.
- Add a cooling off period between resends, and a daily cap per destination.
- Make the limit stricter than normal API limits for authentication and recovery flows. OWASP's authentication guidance says anti brute force protections on these endpoints should be stricter than regular rate limiting.
- Set a spending cap or alert at the provider, so abuse stops even if your code misses it.
- Validate the destination. Reject numbers or addresses in patterns you do not serve, if that fits your business.
- Add a challenge such as a bot check on unauthenticated paid flows.
- Alert on sudden growth in sends, not only on errors.
Do not rely on the client
An app can add its own throttling, but an attacker calls your API directly and skips the app. All limits must be enforced on the server.
Be careful with limits keyed only on network address. Mobile carriers can place many users behind one address, so strict address limits may block real users. Combine signals instead.
Test it
Write a test that calls the endpoint many times with different destinations and confirm that something stops it, whether a rate limit, a daily cap or the provider's ceiling. Test each host that serves the endpoint, since an old version may lack the control.
You can try the demo below to see how an API scan reports on endpoints, and run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how each endpoint is listed, then ask which of yours trigger a paid action.
Quick check
Is CAPTCHA enough?
It helps against simple scripts but is one layer. Keep per destination caps and provider spending limits.
Should the limit count by IP address?
Include it as one signal, but do not use it alone, since many mobile users can share an address.
Sources
- OWASP API Security Top 10 2023, API4 Unrestricted Resource Consumption
- OWASP API Security Top 10 2023, API2 Broken Authentication
Last reviewed: 19 October 2026.
