# API abuse protection that tells your own app from a script

Source: https://kavralab.com/solutions/api-abuse/

**API abuse** is the use of your public or private API endpoints in ways they were never meant for, usually by scripts that bypass your web or mobile app to test credentials, pull prices and stock, create accounts or flood servers. Kavra ties each call to a real, assessed session with signed single-use tokens.

- **Who it hits:** Any product whose app talks to its own API
- **What it costs:** Server load, stolen data, takeovers, lost stock
- **Tools used:** HTTP clients, scripts, proxies, extracted app keys
- **Where to stop it:** On every sensitive endpoint, server side

## What is API abuse?

Every modern website and mobile app is a thin screen on top of an API. The login button calls POST /login. The product page calls a pricing endpoint. The checkout calls an inventory hold. Those endpoints are public in practice, because anyone can open the browser developer tools or inspect the mobile app and see exactly what is called and with which parameters.

API abuse starts when someone calls those endpoints without your app in the middle. A script can send the same requests your app sends, thousands of times per minute, with none of the friction your interface adds. Nothing about the calls is technically broken: the parameters are valid and the responses are what the endpoint is supposed to return. The abuse is in who is calling, how often, and why.

This makes API abuse different from classic security flaws. Patching code does not fix it. Authentication does not fix it either, because many abused endpoints are meant to be used before login, and attackers happily create accounts to reach the ones behind it.

## Common types of API abuse

The same technique, calling your API directly, feeds many different attacks.

| Attack | Endpoints targeted | What the attacker gets |
|---|---|---|
| [Credential stuffing](https://kavralab.com/solutions/credential-stuffing/) | Login, token refresh, password reset | Working username and password pairs, then account takeover |
| [Scraping](https://kavralab.com/solutions/web-scraping/) | Search, product, pricing, availability | Your catalog, prices and stock levels, at machine speed |
| [Inventory hoarding](https://kavralab.com/solutions/scalping/) | Cart, reservation, seat hold | Limited stock held or bought before real customers can reach it |
| [Fake account creation](https://kavralab.com/solutions/fake-accounts/) | Signup, email and phone verification | Accounts in bulk for spam, bonuses or later abuse |
| Account and data checks | "Email exists", gift card balance, coupon validation | Lists of valid users, cards or codes to exploit |
| Layer-7 floods | Search, login, any expensive query | Slow or unavailable service, often as cover for another attack |

## How attackers abuse an API

The playbook is the same whether the target is a sportsbook, a retailer or a bank.

1. **Map the endpoints**: The attacker opens your site with developer tools, or unpacks your mobile app, and records every call, header and parameter it makes.
2. **Copy the credentials the app carries**: Static API keys, client secrets and signing logic shipped inside a web bundle or app binary are extracted and reused.
3. **Script the calls**: An HTTP client replays the requests, tuned to look like a real browser or phone app. For endpoints guarded by client-side checks, a [headless browser](https://kavralab.com/detect/headless-browsers/) runs just enough of the page to get a valid token.
4. **Spread the traffic**: Requests are distributed across [residential and mobile proxies](https://kavralab.com/detect/residential-proxies/) so that no single IP address stands out, and the pace is tuned just under your rate limits.
5. **Harvest and adapt**: Results are collected, and when you change something, the script is updated within hours. The cost of a new version is low, and the payoff repeats every day.

## Who it hits and what it costs

Any business whose app depends on its own API is exposed, which today is almost every business. The cost depends on what the endpoint gives access to. For e-commerce and travel, it is scraped prices and held inventory. For fintech and iGaming, it is login endpoints turned into credential testing machines. For SaaS and AI products, it is expensive compute consumed by scripts.

- Infrastructure cost: bots trigger database queries, search requests and third-party calls you pay for.
- Direct fraud: account takeovers, fake accounts and card or coupon checks that start at the API.
- Lost revenue: competitors undercut your prices in real time, and resellers buy out limited stock.
- Degraded service: real customers see slow pages and timeouts during floods.
- Misleading analytics: automated calls inflate traffic, search and conversion numbers.

## Warning signs of API abuse

Look at the requests your API receives, and ask whether your own app could have sent them.

- **Calls with no app session**: Requests arrive without the page load, app launch or navigation that your real clients always perform first.
- **Systematic parameters**: Product IDs, dates or usernames walked in order, or the full catalog requested in a pattern no shopper follows.
- **Clients that do not add up**: A request claims to be your iOS app or a desktop browser, but its connection and headers belong to a scripting library.
- **Steady machine pace**: Even timing, night and day, and sudden jumps in volume right after you release a new price, drop or promotion.
- **Reused keys and tokens**: The same API key or session token used from many networks at once, or tokens replayed after they were already spent.
- **Low useful outcome**: Many searches with no clicks, many carts with no purchases, many login attempts with a high failure rate.

## Why common API defenses miss it

Traditional API controls were built to stop broken or unauthorized requests. Abusive requests are neither.

| Defense | What it checks | Why abuse gets through |
|---|---|---|
| API keys in the client | That the caller has the key | Anyone can extract a key shipped in a web bundle or app |
| Rate limiting per IP | Volume from one address | Proxy pools spread traffic across thousands of IPs |
| Rate limiting per account | Volume from one user | Attackers create or take over many accounts |
| Web application firewall rules | Known attack payloads | Abusive requests are well formed and use valid parameters |
| Schema validation | That the request is well formed | The script sends exactly the format your app sends |
| CAPTCHA | A human at the screen | APIs have no screen, and scripts call the endpoint after the puzzle |

## How to protect APIs used by your own apps

The endpoints behind your web and mobile apps should answer only to your apps, used by real people. The way to enforce that is to make each sensitive call carry proof that a real, assessed session produced it, and to check that proof on the server before doing any work.

- Assess the visitor in the client, with a script on the web and an SDK in your iOS and Android apps.
- Issue a signed, short-lived token bound to the specific action, such as login, search or add to cart, and refuse it for anything else.
- Make tokens single use. A replayed token is a strong signal of a script and should be refused and logged.
- Verify the token and read the assessment on your server before running the expensive or sensitive part of the request.
- For backend-to-backend and partner traffic, assess requests server side with the same risk logic instead of trusting a static key.
- Rate limit by actor and device, not only by IP address or account.
- Start in observe-only mode on each endpoint, check the results against your logs, then enforce.

> **Key takeaway:** Your API cannot tell your app from a copy of your app by looking at the request alone. Give each sensitive call proof of a real session, check that proof server side, and judge the actor behind the traffic rather than the IP. The same approach stops the [SMS pumping](https://kavralab.com/solutions/sms-pumping/) that targets your OTP endpoint.

## How Kavra stops API abuse

Kavra assesses the client with 3,000+ data points, binds the result to the action in a signed token, and lets your server check it before the endpoint does any work.

- **Signed single-use tokens**: Each token is short-lived and bound to one action. Replays are refused and reported, so scraped or reused tokens are worthless.
- **Server-side request API**: Assess API and backend traffic directly from your server, including calls that never pass through a browser.
- **Native iOS and Android SDKs**: Your mobile app proves it is your real app on a real device, so emulators and scripted copies of the app stand out.
- **Automation and impostors exposed**: HTTP clients imitating browsers, headless Chrome and stealth plugins are caught by contradictions between network, device and behavior.
- **Verified good bots**: Search crawlers and AI agents that sign their requests are recognized, so you can allow them while blocking impostors using their names.
- **Floods and campaigns flagged**: Layer-7 floods, surges of new devices and shared infrastructure across your endpoints are grouped into one campaign you can act on.

## FAQ

### What is the difference between API abuse and an API attack?

An API attack usually exploits a flaw, such as broken authorization or an injection bug, and is fixed in code. API abuse uses endpoints exactly as designed, with valid requests, but at machine scale or for a harmful purpose. Fixing bugs does not stop it; recognizing who is calling does.

### How do you detect bots calling your API directly?

Check whether a real, assessed session stands behind each call. Bots that skip your app have no page load, no app launch and no valid single-use token, and their connection often contradicts the browser or app they claim to be. Server-side checks on those signals catch them without any user-facing puzzle.

### Is rate limiting enough to prevent API abuse?

No. Rate limits per IP or per key only cap volume from one source. Attackers spread requests across proxy pools and many accounts, staying under every limit. Rate limiting is still useful for floods, but it works far better when it counts per actor and device rather than per address.

### Can you hide API keys in a mobile app?

Not reliably. Anything shipped inside an app binary or web bundle can be extracted with free tools. Treat embedded keys as identifiers, not secrets. Real protection comes from short-lived tokens that prove a genuine app on a genuine device made the request, checked on your server.

### How do I protect a public API without breaking legitimate integrations?

Separate the traffic. Partners and documented integrations get their own credentials and server-side checks. Endpoints used by your own web and mobile apps require signed session tokens. Verified good bots and AI agents can be allowed by policy, while unverified clients claiming to be them are flagged.

### Does a web application firewall stop API abuse?

Partly. A firewall blocks known malicious payloads and some floods, but abusive requests look like normal traffic: valid parameters, correct format, ordinary volume per IP. Stopping them needs evidence about the client and the actor behind it, which a firewall rule does not see.

---
Kavra Lab: bot and fraud detection that explains every decision. Book a demo: https://kavralab.com/contact/