API abuse

What it means

API abuse is using an API in the way it was built to be used, but for a purpose or at a volume that harms you. Nothing is broken. A script calls a public search endpoint a million times, or an account creates thousands of free trials. No password is guessed and no weakness is exploited; the API simply does what it is asked, over and over.

That is what separates it from a vulnerability. There is no bug to patch. The behaviour is allowed, and the only question is whether you set sensible limits on how much, how fast and by whom. That makes it a design and monitoring problem more than a coding one, and fixing it takes a decision about what normal use looks like.

Why it matters

The costs are practical: scraped catalogues and customer lists, inflated cloud bills, free credit farmed away, inventory held by bots, and genuine customers slowed down. OWASP groups the sensitive cases under unrestricted access to sensitive business flows, and the resource cases under unrestricted resource consumption. Every one of these shows up on a bill or a dashboard, not in a security alert.

Because each request is valid, tools that look for attacks see nothing wrong. You often find out through a bill, a complaint or a competitor who suddenly knows your prices. Customers notice before the dashboards do. A competitor who suddenly matches your prices or a surprise cloud invoice is often the first alert you get.

How it shows up

You meet it in sign-up, search, price and stock lookups, password reset, referral, voucher and export features, and anywhere an action has a value. Typical gaps are limits keyed only on IP address, no cap per account, no check for automation, and no alert when usage jumps.

Responses combine controls: rate limits per account and per action, quotas, bot detection on sensitive flows, step-up checks such as a code, usage alerts, and a way to revoke a key quickly. Decide which actions are valuable first, then protect those. See also business logic flaws.