A Denial of Wallet (DoW) is an interesting resource exhaustion attack as its aim is not to cause an outage or a defaced homepage. In fact, the longer the targeted service stays up for, the more successful it is. DoW is an attack that turns you r cloud bill into the target instead of your availability.
It's the evolution of resource exhaustion for a world where infrastructure is no longer a couple of on-prem servers that eventually fail under sustained load. It leverages auto-scaling and serverless environments by continuously using and abusing elasticity to run up your invoice.
DoS vs Denial of Wallet
For most of the internet's history, attacks targeted capacity. If you flood a server hard enough that it runs out of CPU, memory, sockets, or bandwidth, the service crashes, rendering it offline. This makes the failure visible and self limiting.
Cloud economics changed this model, as instead of simply exhausting a fixed pool of resources, modern applications respond by automatically adding more compute, invoking more serverless functions, or processing more metered API requests based on demand.
How?
Almost any metered system supplies the 3 key requirements for DoW:
- An operation that is cheap to request but expensive to serve. One HTTP request that triggers an image render, a database scan, a serverless function, or a paid API call. This does not cost the attacker anything, but the operator spends money every time it runs.
- A way to defeat caching by sending unique inputs so nothing is served from cache. A wordlist, incrementing IDs, or random query strings that would not be in cache.
- Elasticity to do the spending: an autoscaler, pay per invocation runtime, or metered API that complies with the requests.
Basically, find the metered door, knock on it with unique inputs faster than cache or people can react, and let the infrastructure run up the tab.
Uses
- Pay per use AI, LLM, and embedding APIs.
- Serverless functions billed per invocation and duration.
- Autoscaling compute that reacts to synthetic load by buying more nodes.
- Egress bandwidth, where large downloads are cheap to request but expensive to serve.
- SMS, email, log ingestion, CDN services, and search indexing. Anything that is publicly reachable and billed by usage.
AI features have made denial of wallet much easier to find in the form of chatbots, semantic searches, document summarisers, image generators, or embedding endpoint often hides a paid API behind a simple HTTP request. Without authentication, quotas, or rate limits, those features can be easily exploited.
My run in with it
I found mine when I got a notification of a sudden traffic spike from this very platform. Over about an hour, my traffic graph spiked to 500x which only happens with fresh Reddit/YouTube mentions. The traffic pattern used hundreds of requests sent to /search, and every one used a different query. It followed a strict alphabetical wordlist of technical terms, like Account SID, ACME, Active Directory, Argon2, ChaCha20, Curve25519, DNSSEC. It was a script feeding a dictionary into my search box.
At that time my search wasn't a plain keyword lookup, it surfaced results using semantic matches, which meant embedding every visitor query through a metered, per-call API. Because every query was unique, there was nothing to cache and every request became a fresh charge. I already had multiple layers of caps and limits in place, so it did not manage to run up my bills, but it tried to.
I then noticed that every single post on the site had a visit logged within the same time frame (not just the latest/popular ones, literally all of them) and clocked that the search terms weren't actually a random wordlist; they were my own glossary, term for term. Something had read the glossary page I built to define jargon and turned it into a manifest/dictionary. The evasion technique was quite clever as there were hundreds of requests from hundreds of IP addresses across unrelated cloud and hosting providers, every single one reporting the exact same browser and OS, arriving in synchronised waves, in order to avoid being rate limited.
At that point I realised that this wasn't just DoW, it was a full scraping infrastructure running through every page on the site, with headless browsers spawning from hundreds of IPs, looking up glossary terms and their related posts, most likely scraping content in a very odd, roundabout way.
Defence
You cannot stop DoW by adding capacity as capacity is being weaponised.
- Don't expose metered work directly to anonymous users.
- Rate limit expensive operations per identity, not just globally.
- Put hard spend caps on every paid service.
- Alert on spend rate, not just total monthly spend.
- Precompute and cache wherever possible.
- Gracefully degrade features when budget thresholds are reached.
- Push coarse rate limits to the CDN or WAF so abusive traffic never reaches the expensive path.
To treat every paid operation like CPU or memory: give it a budget, enforce that budget at the edge, in the app, and at the account level.