Rate limiting for websites and APIs: slow down bursts, not your customers
One script in a hurry is enough to tie up your server: a scraper working through your pages, a burst of password attempts, an API client stuck in a loop. Klacos counts requests in front of your site and slows down whoever sends too many, before they reach your server. The response tells them when to come back, and an ordinary visitor stays well below the limits.
Why a single client can slow down a whole site
A server busy for everyone
A scraper asking for page after page, or a script trying passwords, keeps your server busy. Meanwhile, your customers wait.
The routes that cost the most
Sign-in, search, export, APIs: each call costs far more than a cached page, and these are the routes scripts repeat.
A blind limit punishes people
Behind one address there may be a whole office, or the customers of a mobile operator. A limit set too low and applied without judgement blocks them all.
What you should expect from rate limiting: limits at several levels, a response that says when to come back, and a decision that takes into account who is sending the requests, not just how many there are.
Each limit stops a different kind of abuse
The per-address limit stops a lone machine that has run away with itself. The limit per address block and per operator stops whoever spreads requests across many addresses to stay under the radar. The per-route limit protects what’s expensive: the sign-in page, checkout, a search API.
Each limit is set per site and per type of traffic (pages, APIs, files), and applies without a restart. It follows the rule that runs through all of your protection: observe first, decide next, enforce last. In observation, anything over the limit is counted and shown in the console without being enforced, so you see who would be slowed down before anything is enforced.
This net holds at all times, even before bot management has judged a visit: a script that arrives in a burst is slowed down while it’s still being assessed.
What gets stopped in front of your site, and what doesn’t
An attack doesn’t have to be huge to take a site down: a handful of machines hammering the right route will do it. These application-layer attacks go after your web service itself, and that’s where Klacos stops them.
Stopped before your server
- floods of HTTP requests on a page, a search or an export;
- password attempts in bulk on your login page;
- API abuse, from a client stuck in a loop or a script scraping it;
- slow connections that drag on, and bursts of new connections;
- requests with oversized headers or bodies.
Not covered
- volumetric attacks that saturate the network link before reaching a web service: those are handled by your hosting provider or network operator.
Slow down without banning
A client that goes over a limit gets a response asking it to wait, and saying for how long. It isn’t banned: as soon as its pace is back to normal, it gets through. The limits are designed with shared addresses in mind, so a whole office or a mobile network doesn’t pay for one neighbour in a hurry.
A partner that has to send a lot of requests, such as an uptime monitor or the provider that confirms your payments, is let through with an access rule. Injection attempts are a job for the web application firewall. Rate limiting is one of the capabilities that make up your site’s protection, all sharing the same read of each visit.
Limits at every level, tuned for your site
Per address
Per network and operator
Per route
A clear response
Slow down, not ban
Changed on the fly
Slow connections
Oversized requests
Questions about rate limiting
Can a limit block my customers?
It slows clients down rather than banning them: a client that goes over gets a response telling it when to come back, and gets through again once its pace is normal. You can start in observation to see who would be affected before you enforce anything.
Do my APIs get their own limits?
Yes. APIs are a separate type of traffic, and each sensitive route, such as sign-in or search, can have its own limit. A rate-limited API call gets a response a program can read, with the delay to respect.
Is this DDoS protection?
For application-layer attacks, yes: request floods, slow connections, password attempts in bulk, API abuse. A volumetric attack that saturates the network link before it reaches a web service isn’t covered: that’s a job for your hosting provider or network operator.
Do I need to change my application?
No. Limits are set in the Klacos console, in front of your server, which stays as it is.
See who would be slowed down, before you slow anyone down
Request early access: limits start in observation, on your own traffic. Or talk to us about the routes and APIs you want to protect.