Picture a shop with no till limits, no security guard, and a door that never locks, where anyone can walk in and take as much as they like, as often as they like, all day and all night. That is roughly what an API without rate limiting looks like to the automated scripts that spend their days searching for exactly this kind of opening across the internet.
An Endpoint With No Throttle Is an Invitation
APIs exist to move data quickly between systems, which makes them wonderfully efficient and, without the right controls, wonderfully easy to abuse at scale. If an endpoint accepts requests without limit, a script can hammer it thousands of times a minute, scraping pricing data, testing stolen card numbers, or brute-forcing account credentials, and your servers will simply keep answering because nothing was ever told to stop them. Developers building the endpoint were focused on making it fast and functional, not on imagining a hostile script hammering it around the clock.
Thorough API pen testing routinely uncovers this exact gap: endpoints that respond identically whether they receive ten requests an hour or ten thousand, with no throttling, no anomaly alerts, and no meaningful difference in behaviour between a genuine customer and a script running unattended overnight while everyone else is asleep.
Scraping, Brute Force, and the Silent Cost of Doing Nothing
The damage from an unthrottled API rarely announces itself with an alarm bell. Competitors quietly scrape your pricing to undercut you within the hour, sometimes automatically adjusting their own listings in near real time. Fraudsters test thousands of card numbers against your payment endpoint, and each failed attempt costs you processing fees even when the transaction never completes successfully. Account credentials get tested at industrial scale against login endpoints that never seem to notice the pattern until customers start complaining about locked-out accounts. By the time finance notices the payment processing fees creeping upward, the abuse has often been running quietly for weeks.
When we raise this with clients, one point tends to land harder than the rest.
“I have seen a single unprotected endpoint handle over a million automated requests in a weekend before anyone in the business noticed anything was wrong at all. The API was working exactly as built, which was the whole problem, because nobody had told it how much traffic was too much traffic.”
— William Fieldhouse, Director of Aardwolf Security Ltd
That is the uncomfortable truth about most API abuse: the system behaves perfectly, technically speaking, right up until the business impact becomes undeniable to everyone involved. Rate limiting is not a complex fix, but it needs to be deliberate, tuned to real usage patterns, and tested against the ways attackers actually try to slip past it rather than the ways a developer merely assumed they would try.
Put a Limit on the Buffet
Every API should have a ceiling on how much any single client can request in a given window, paired with monitoring that flags the moment normal usage tips into abuse. Building that ceiling well takes an outside perspective that knows how attackers actually probe these systems, which is exactly why organisations serious about protecting their data work with the best pen testing company they can find rather than guessing at limits alone and hoping for the best. Set the ceiling too low and you frustrate genuine customers; set it too high and you have built nothing but a formality that never actually stops anyone determined to abuse it.