Evaluate WAF and API gateway signals with one question: can your edge tell a request from your genuine, unmodified app apart from scripts, emulator farms and legitimate automation, before the request reaches business logic? Otukan’s protected app attaches evidence of app identity and runtime state to the calls you choose. Your WAF or API gateway verifies that evidence and applies a rule per route: allow, rate-limit, challenge or refuse. Decisions that need account or transaction context stay in your backend. Evidence is scoped separately for Android and iOS, and every rule runs on infrastructure you control.
The wider set of API controls is covered on mobile API protection.
Abuse path
At the edge, three kinds of traffic can look alike. A good evaluation separates them before any rule is written.
| Traffic | What it is | What the edge sees without client evidence | What changes with Otukan evidence |
|---|---|---|---|
| Automated requests | Scripts and tools calling your API directly | Plausible headers, rotating addresses, normal-looking payloads | No valid evidence, so verification fails on protected routes |
| Invalid clients | Repackaged, hooked or emulated copies of your app | Traffic that looks exactly like your app | Evidence arrives but reports tampering, runtime risk or an unknown build |
| Legitimate automation | Partner integrations, uptime probes, your own test suites | Machine traffic that must keep working | Recognised on its own path first, so app-evidence rules never judge it |
Why the split matters for the gateway
Address reputation and request rate catch crude automation, but scripts that pace themselves and rotate addresses pass. Client evidence answers a different question: not how the request behaves, but what sent it. Legitimate automation needs its own lane, because it will never carry mobile app evidence and should not be treated as if it failed.
Enforcement boundary
Three layers make decisions, and each is good at different ones. Put each decision where the right information is.
| Layer | Decides well | Should not decide |
|---|---|---|
| The app | What to do on the device in the moment, such as hiding a screen or stopping a flow | Whether a request is trustworthy; the device may be under an attacker’s control |
| WAF or API gateway | Per-route admission based on verified client evidence, rate classes and challenges | Whether a transfer or account change is legitimate for this customer |
| Backend | Account, value, history and fraud context for each sensitive action | Coarse filtering that the edge can do earlier and more cheaply |
What the gateway needs from Otukan
Your gateway team works against Otukan’s verification contract. It states what arrives with each protected call, how the gateway validates it and how long it stays valid. Each call resolves to a client class, such as genuine app, genuine app with runtime risk, or no valid evidence, so edge rules stay short and readable. Otukan fits your existing build and release pipeline, and nothing in the request path requires handing Otukan your API secrets.
Continuity
Edge rules must keep genuine customers moving on a bad day. Write down four policies per route before switching anything to enforcement.
| Policy | Question to settle | A sensible starting point |
|---|---|---|
| Rate | Which limit applies to each client class? | Normal limits for genuine app traffic; tighter ones for calls without valid evidence |
| Challenge | What challenge can a mobile user actually complete? | Step-up authentication inside the app rather than a browser-style puzzle |
| Retry | How do genuine app retries differ from automated loops? | Accept retries that carry fresh evidence; back off on stale or reused evidence |
| Failure | What happens when verification is unavailable? | Fail open and record on reads; step up on sign-in; fail closed on payments |
Rolling out without surprises
Start every route in observe mode: verification results are recorded, nothing is enforced. Measure how often genuine traffic fails, for example on old app versions or unusual devices, then enforce route by route.
Proving the setup
Before enforcement, prove each route three ways. In an authorised lab, send the abuse case and confirm the edge classifies it as expected. Walk the same journey with a genuine protected build on a supported device and confirm it passes untouched. Then rerun install, update, sign-in and the route’s most sensitive call on the release candidate, recording versions, results and reviewer.
For credential and bot abuse beyond the edge, see mobile bot detection.