Defeat automated attacks by finding which abuse of your own features is most costly, then layering rate limits, strong authentication, business logic checks and monitoring of outcomes. OWASP's Automated Threats to Web Applications gives names for the patterns, so you can test each one against your app.
What counts as an automated attack?
The OWASP Automated Threats to Web Applications project defines these as misuse of an application's normal functions at scale, not exploitation of coding bugs. Its taxonomy lists a set of named threats, including credential stuffing, credential cracking, carding, scraping, scalping, account creation abuse, denial of inventory and token cracking.
The point of the taxonomy is that these attacks often send perfectly valid requests. A scanner for injection flaws finds nothing, because the code works as designed. The defence has to look at behaviour and business meaning.
Which ones should you prioritise?
Pick by what your application sells or stores.
- A login form faces credential stuffing and cracking.
- A checkout faces carding, where stolen card numbers are tested with small purchases.
- A ticketing or retail launch faces scalping and denial of inventory.
- A public catalogue faces scraping.
- A sign-up form faces fake account creation, which feeds the others.
Rank them by loss: fraud cost, support cost, infrastructure cost, brand harm. Spend effort at the top of that list.
What defences work together?
No single control stops a determined actor. The aim is to make each attempt cost more than it earns.
Rate limits with several keys. Limit by IP address, but also by account, by device identifier and by payment instrument. Attackers rotate addresses. They find it harder to rotate everything.
Strong authentication. For login abuse, multi-factor authentication removes most of the value of a stolen password. NIST SP 800-63B also recommends checking new passwords against lists of known compromised values, and throttling failed attempts.
Friction when risk rises. Add a challenge only when signals are odd: a burst of failures, a new device, an unusual path through the app. Constant challenges annoy real users.
Business logic limits. Cap the quantity per order, the number of coupon tries and the frequency of gift card balance checks. Many automated attacks collapse against limits the business already understands.
Hide uniform responses. Return the same message and timing for unknown user and wrong password, so attackers cannot learn which accounts exist. The OWASP Authentication Cheat Sheet covers this.
Bot signals. Use behavioural and network signals as one input, not the only verdict. Allow legitimate automation through documented, authenticated APIs.
How do you measure whether it works?
Watch outcomes, not blocked requests. A blocked request count says little. These numbers say more: failed login rate per hour, share of new accounts that never complete a profile, chargebacks per thousand orders, share of inventory bought by accounts under a day old, and origin traffic cost per genuine order.
Alert on sudden shifts in those ratios. They catch attacks that stay under every threshold.
A constructed example
A small retailer sells limited edition items. On launch day, 95 percent of stock sells in four minutes, mostly to accounts created that morning, shipped to a handful of addresses. The team adds three controls: a per-address purchase limit, a delay before new accounts can buy limited items, and a queue that admits customers at a measured rate. Next launch, stock lasts three hours and the account creation spike disappears. No scanner would have found the problem, because nothing in the code was broken.
How to check or apply this
- List your valuable functions: login, sign-up, checkout, search, API.
- For each, match the relevant OWASP automated threat names.
- Estimate loss per threat and rank them.
- Add layered limits keyed to account, device, address and payment.
- Require multi-factor authentication where accounts hold value.
- Log business events with enough context to spot abuse later.
- Track outcome ratios and review them weekly.
- Test your own limits from a controlled environment you own.
Quick check
Is a web application firewall enough against automated attacks?
Rarely by itself. These attacks use valid requests, so you also need account level limits, authentication controls and logic checks inside the application.
Does a CAPTCHA stop credential stuffing?
It adds cost but does not remove the threat. Multi-factor authentication and breached password checks address the root issue.
Sources
Last reviewed: 18 October 2026.
