Rate Limiting & Resource Abuse

APIs that lack proper rate limiting are vulnerable to Denial of Service (DoS), brute force attacks, and resource exhaustion. Attackers can also abuse business logic flows (like purchasing or voting) if they are not rate-limited.

Rate Limiting Detection

First, determine if rate limiting is in place and what the limits are.

Basic testing

Send a burst of requests and check the response codes.

for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -H "Authorization: Bearer $TOKEN" \
    https://api.target.com/api/users
done | sort | uniq -c

Response headers

Check for headers that indicate rate limits.

curl -v https://api.target.com/api/users 2>&1 | grep -i rate

# Common headers:
# X-RateLimit-Limit: 100
# X-RateLimit-Remaining: 99
# X-RateLimit-Reset: 1640000000
# Retry-After: 60

Rate Limit Bypass

If rate limiting is detected, try to bypass it using various techniques.

1. IP rotation

If limits are IP-based, rotate your IP address.

curl --proxy socks5://127.0.0.1:9050 https://api.target.com/api/users

2. Header manipulation

Spoof your IP address using headers like X-Forwarded-For.

curl -H "X-Forwarded-For: 127.0.0.1" https://api.target.com/api/users
curl -H "X-Real-IP: 10.0.0.1" https://api.target.com/api/users
curl -H "X-Originating-IP: 192.168.1.1" https://api.target.com/api/users
curl -H "X-Client-IP: 172.16.0.1" https://api.target.com/api/users

3. Endpoint variation

Try different versions or case variations of the endpoint.

• /api/v1/users
• /api/v2/users
• /api/users
• /v1/api/users
• /api/Users
• /API/USERS
• /Api/Users
• /api/users/
• /api/users%20
• /api/users%00

Resource Consumption (API4)

Test for endpoints that consume excessive resources.

Large response testing

Request large amounts of data via pagination or limit parameters.

GET /api/users?limit=10000
GET /api/users?page=1&per_page=999999
GET /api/search?q=a&results=all

Deep pagination

Requesting very high page numbers can stress the database.

GET /api/items?page=1000000

Field expansion

Requesting all fields or nested relations can be expensive.

GET /api/users?fields=*
GET /api/users?include=all,nested,relations

Batch requests

Send a large number of operations in a single batch request.

POST /api/batch
Content-Type: application/json

{"ids": [1,2,3,...thousands of IDs...]}

Sensitive Business Flows (API6)

Resource consumption is about the cost of one request. This category is about a legitimate sequence being repeated at machine speed, where every individual call is small, cheap and correctly authorized — and the business outcome is still catastrophic. A thousand requests can each be fine while the thousandth order drains the last unit of stock, and no volume limit ever fires.

1. Enumerate flows, not endpoints

Walk the product the way a user does and write down each multi-step flow: registration and verification, add-to-cart and checkout, invite and referral credit, password reset, coupon redemption, posting, voting, reservation holds, refunds and cancellations.

2. Write down the invariant

Each flow has a rule the business believes is true: one per customer, one coupon per order, one vote per account, a hold expires in ten minutes, a refund cannot exceed the charge. The vulnerability is the gap between that rule and what the API enforces.

3. Break it with concurrency, not volume

Sequential requests usually behave. Send the same request in parallel so every worker passes the "has this account already redeemed?" check before any of them commits:

# 50 simultaneous redemptions of one single-use coupon, one valid session
redeem() {
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://api.target.com/api/coupons/redeem \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"code":"ONCE-ONLY"}'
}
for i in $(seq 50); do redeem & done | sort | uniq -c

# More than one 200 means the check-then-act is not atomic

4. Price the damage

A finding is only actionable with a number: units of stock held, margin lost per abusive order, credits minted per referral loop, minutes of human support consumed per fake registration. Measure it on the engagement's fixtures, never by burning a real inventory.

5. Per-IP limits do not help here

Abuse of an authenticated flow needs one valid session, not many addresses. If the only control is an IP rate limit, an attacker with a single account and one residential connection is already inside it — and a second account defeats per-account limits only if nothing binds the two (device, payment instrument, verified email domain).

Evidence Collection

False Positive Identification

Testing Checklist

Remediation & Defense