Mobile API abuse: the bot traffic your web defences never see

The app package is public documentation

Assume anything inside the shipped app is known: endpoint paths, request signing schemes, embedded API keys, and the logic that assembles a valid call. Reverse engineering tools are mature, and a competent analyst can have a working replay of a retail app's core calls in days. Security built on the secrecy of the app internals is not security. It is a delay, priced in analyst hours.

That changes the design question. The API cannot trust a request because it looks right. It has to ask what proves this call came from a genuine, unmodified app running on a real device, and what the cost of faking that proof is. Everything else, header checks, user agent strings, even well built request signatures, can be copied once observed.

Attestation raises the price, it does not end the game

Platform attestation services, Apple's App Attest and Google's Play Integrity, let a backend verify that requests come from a genuine app install on a genuine device, with signals about tampering and automation. Attackers respond with device farms and emulators tuned to pass checks, which is why attestation works as economics rather than as a wall: it moves abuse from a cheap script on a server to hardware, accounts, and maintenance.

Bind tokens to the attested install and keep them short lived. A replayed request carrying a token minted for another install, or an expired session, should fail even if its format is perfect. Pair that with per install rate limits on the expensive endpoints, search, pricing, inventory checks, login, and the replay farm has to spread across installs the way residential proxy abuse spreads across addresses, becoming visible in the aggregate pattern.

The endpoints that get hit, in order

Pricing and inventory reads go first, because they are unauthenticated by design and valuable to competitors and reseller bots alike. Then login and account creation, where the API path often skips the step up checks the web team added to the site months ago. Then the money endpoints: gift card balance, coupon validation, loyalty. Audit the API by asking, for each endpoint, whether the same action on the website carries a control the API version lacks. The gaps in that list are the attack plan, already written.

Version drift is the quiet multiplier. Old app versions stay in use for years, and their API versions stay live to support them, frozen with yesterday's weaker controls. An attacker picks the oldest supported version deliberately. Forcing minimum versions is unpopular with app teams and unavoidable for risk teams, and the compromise is a published support window that security can plan around.

Web analytics will not save you here because this traffic never renders a page. Log at the API gateway with install identity, endpoint, response size, and timing, and review it the way you review web traffic: top installs by calls, error distributions, geographic spread against your customer map. A single install making search calls at the rate of a comparison site is not a power shopper.

Build the API its own telemetry

Start with visibility before controls. Most retailers who instrument their API properly find the abuse in the first month of looking, priced in bandwidth, in scraped prices showing up in competitor repricers, and in account takeovers that the web logs could never explain. The side door was never locked. It was just never watched.

Frequently asked questions