A mobile security team should evaluate mobile bot detection on three questions: can it tell a scripted or modified client from the genuine app without catching approved automation; where does each decision sit between the app, the API gateway and the backend; and what happens to real users when evidence is missing, a challenge fails or traffic surges. This guide is for fraud, API and mobile engineering leads comparing options for Android and iOS apps. It covers traffic that reaches your mobile APIs. Web bot management and network-level volumetric attacks sit outside it, and every answer should be tested on your own endpoints.
For the control on its own, see mobile bot detection. The wider request-trust model is covered on mobile API protection.
Abuse path: who is calling your API
Most mobile bot traffic never touches a phone screen. It is a script replaying requests it learned from the app, a modified build running on an emulator farm, or a real device driven by automation. Your evaluation should start by sorting callers into three groups and asking each option how it treats them.
Automated requests
- Which endpoints attract scripted traffic today: login, sign-up, one-time codes, search, fares, stock or promotions?
- Do attackers call your API directly, without any app, using requests captured from a real session?
- Can a captured request be replayed minutes or hours later and still succeed?
Invalid clients
- Do modified or repackaged copies of your app exist, and do they call the same endpoints?
- Do you see traffic from emulators or device farms that present themselves as ordinary phones?
- Are real phones being driven by automation tools or misused accessibility services to tap through your flows?
- Can the option report hooking, debugging and repackaging together with the request, rather than in a separate console?
Legitimate automation
- Which automation must keep working: your UI test suite, synthetic monitoring, partner integrations, assistive technologies?
- How are approved automated callers identified, and who maintains that list?
- How will you prove, before enforcement, that none of them is rejected?
How Otukan answers. Otukan bot detection separates scripted API clients, emulators, device farms and bots driving real phones from people using your genuine app. The protected app attaches evidence of app identity, device state and request freshness to the calls you choose, and reports emulators, hooking, debugging and repackaged copies alongside each request. Evidence is short-lived and bound to the request, so a captured call replayed later fails verification. Installs with matching traits are grouped, so a device farm shows up as one cluster rather than many unrelated phones. Before enforcement, we build a baseline of your legitimate automation with you, from QA device farms to assistive tools, so it keeps working when enforcement starts.
Enforcement boundary: where each decision sits
A bot decision made in only one place is either too blunt or too late. Map your three layers and give each a job.
| Layer | What it knows | What it should decide |
|---|---|---|
| The app | Device state, app integrity, runtime conditions | Nothing final; it collects and attaches evidence |
| API gateway | Volume, origin, evidence present or absent | Coarse filtering and rate limits per endpoint |
| Backend service | Account, transaction and business context | Allow, step up or reject for this user and this action |
| Fraud or risk engine | History across sessions and channels | Scoring and case review |
- Where is evidence verified today, and can that service reach it before business logic runs?
- Which endpoints need a hard decision and which only need a signal for later review?
- Who owns the policy at each layer, and who approves a change to it?
- Does the option keep app-side checks from making final decisions an attacker could patch out?
How Otukan answers. Otukan evidence is verified in your API gateway or backend service before business logic runs, so the decision stays on infrastructure you control. You set an allow, step-up or reject outcome per endpoint. Failed verifications are recorded with endpoint, time and reason, which gives your security team and your fraud engine a clean input.
Continuity: rate, challenge, retry and failure
Bot controls fail in production when nobody wrote down the edge cases. Settle these policies in writing and test each one.
Rate and challenge
- Which rate limits apply per account, per device and per endpoint, and do they differ for requests with valid evidence?
- Which challenge follows a doubtful request: a one-time code, re-authentication, a delay or a manual review?
- How does a real user complete that challenge on a slow connection or an older device?
Retry and failure
- How does the app retry when verification fails, and can retries themselves look like abuse?
- What happens when evidence is missing because the app is outdated or the network dropped mid-request?
- For each endpoint, does a missing check fail open, step up or fail closed?
- How long do you run in observe mode, and what result lets you switch to enforcement?
How Otukan answers. You choose per endpoint whether a request with missing evidence fails open, steps up or fails closed, and you can run in observe mode first to see what enforcement would change. Otukan protects Android and iOS apps, including Flutter and React Native, with bot detection scoped separately per platform. It fits your existing build and release pipeline, and your signing keys stay with your team.
For a broader checklist across every control, see the mobile app security evaluation checklist. Login-focused attacks are covered on credential stuffing protection.