Yes - and it is the attack most setups are blind to. The shape is an asymmetric-cost endpoint: one easy click for a visitor, but real work for your server. "Download everything as one file." "Generate my PDF report." "Export the whole dataset." One click for them can be thirty seconds of sweat for you.
Why your defenses miss it. An attacker does not need an army - they just keep triggering that one expensive thing from a handful of different addresses. Two things then fail at once. Most alarms listen for error responses (floods of 404s, failed logins), but this request returns a perfectly normal success, so the alarm never rings while your server is pinned. And because the attacker rotates addresses, a "too many requests from one address" limit never trips either. It is a denial of service made entirely of 200s.
The fix, in order of preference. Do not rebuild the expensive thing on every request: build it a few times a day on a schedule and hand everyone the same ready-made copy - bake the bread each morning rather than from scratch per customer. If something genuinely must be built on demand, allow only a couple to build at the same time (a concurrency cap), so a flood queues instead of all landing at once. Make sure tacking junk parameters onto the URL cannot trick you into rebuilding - the cache key should ignore them and serve the ready copy. And limit abuse per-network as well as per-address, since attackers hop between addresses in the same neighbourhood.
The practical move: audit your app specifically for "cheap request, expensive response" endpoints and protect those. They are the take-it-down vector even when everything else is well rate-limited. For large file downloads the cleanest fix is different - serve them from edge object storage. Full item with the semaphore pattern: https://www.tigzig.com/security/backend.
← All Agents FAQ