Rate-Limit & Abuse Tuner

A browser-based lab where you configure rate limits for a fictional API at api.shop.example (login, catalogue, SMS send-code, password reset and orders) and replay a seeded 24-hour traffic trace through them. You see which attacks got through, which real users and partners you blocked, what SMS pumping cost, and which alerts fired. Then you tune once and replay for a grade.

Credential stuffing tools spread attempts across thousands of IP addresses, often residential proxies, so each IP sends only a request or two a minute. That is below any per-IP limit a real office, campus or mobile carrier could live with, because many genuine people share one IP behind NAT. Each username is also tried about once, so a per-username limit never trips. What stops it is controlling the login flow: breached-password checks, failed-login ratio monitoring across all sources, and step-up MFA for risky logins.

API4:2023 Unrestricted Resource Consumption (missing or badly sized limits, burst handling, partner and internal quotas, and spend on paid integrations such as SMS) and API6:2023 Unrestricted Access to Sensitive Business Flows (automated abuse of login, scraping of the catalogue, enumeration through password reset). Where OWASP places part of a problem elsewhere, the debrief says so: credential stuffing is also listed under API2 Broken Authentication.

A fixed window is cheap but lets a client send up to twice the limit across a window edge. A sliding window removes that edge effect but has no room for bursts, so a page load that fires a dozen calls at once can be rejected. A token bucket refills at the limit rate and holds up to the burst size, so ordinary bursts pass while the sustained rate stays capped. In the lab, token buckets usually fit people and partners, and sliding windows fit low per-hour limits on sensitive flows like send-code and reset.

SMS pumping (also called SMS toll fraud or artificially inflated traffic) is abuse of a send-code endpoint to trigger many text messages to number ranges the attacker profits from. The victim pays for every message. Rate limits keyed on IP barely slow it; controls that work include a per-phone-number limit, blocking destination countries and premium ranges you do not serve, a challenge before sending, and a spend circuit breaker. The lab counts cost in illustrative units, not real prices.

No. Every request, user and attacker is simulated in your browser from a seed, using .example hostnames. Traffic sizes, CAPTCHA solve rates and SMS cost units are sim parameters chosen to make the trade-offs visible, not measurements of any real service. A seed reproduces the same day exactly, so you can share a seed and compare designs.

Yes. The lab, all three difficulty levels, the tune round and the debrief are free. Signing in lets your best grade follow your account.