Finding an IDOR That the Web Testers Missed

A target I tested had already been through two rounds of web app testing. The web client was solid, object-level authorization was enforced consistently across every endpoint the browser touched. The mobile app, though, had never been in scope for either engagement.

Same backend, different client, different endpoints

The assumption on a lot of programs is that “the API” is a single surface, and if the web app is locked down, the API is locked down. That’s rarely true in practice. Mobile clients frequently hit endpoints the web app never calls at all, things like bulk sync routes on app launch, background refresh calls that fire while the app’s just sitting in the background, or older API versions kept alive purely to support app builds still installed on people’s phones from months or years ago.

Web testers work almost entirely from what shows up in the browser’s network tab. That’s a reasonable place to start, but it also means the scope of testing quietly narrows to whatever the browser happens to call, without anyone necessarily deciding that on purpose. If the mobile app was never part of the engagement, none of its traffic ever got looked at, and any endpoints unique to it just sat there unreviewed.

Pulling the Android app’s traffic through a proxy turned up exactly that kind of gap: a /v1/sync/user-documents endpoint the web client had no code path to reach at all. It existed purely to let the mobile app batch-fetch a user’s documents on launch, presumably so the app could show a document list immediately without a dozen separate loading spinners.

The actual bug

The endpoint took a userId parameter and returned that user’s documents. Swapping in another user’s numeric ID returned their documents too, no ownership check against the authenticated session anywhere in the flow. A textbook IDOR, the kind that’s usually caught early in a review, except this one was only reachable through a request shape the web testers never had a reason to construct, since the browser client never sent anything like it.

POST /v1/sync/user-documents
{
  "userId": 10482,
  "since": 0
}

Changing userId to a sequential neighbor returned a different user’s full document set, no additional auth check anywhere in the response path. No rate limiting either, so walking through a range of IDs and pulling back document sets one after another wasn’t hard to automate.

Why this happened

It’s worth asking why a bug this basic survived two rounds of testing on the same backend. The likely answer is that the endpoint’s authorization logic was probably fine in the tester’s mental model, since the equivalent web-facing endpoints all did the ownership check correctly. Whoever built /v1/sync/user-documents for the mobile team most likely copied the general shape of an existing endpoint but missed wiring in the same session-based ownership check the others had. Nobody caught it because nobody was looking at mobile traffic in the first place.

This is a common failure mode on APIs shared between a web app and a mobile app built by different teams or added at different times. The web endpoints get reviewed because they’re visible during normal web testing. The mobile-only endpoints exist in a blind spot unless someone specifically goes looking for them.

Why this matters for how you test

If you’re used to testing web apps, it’s natural to assume the API surface is whatever the browser’s network tab shows you. On a target with a mobile client, that assumption leaves an entire class of endpoints completely untested, not because anyone decided to skip them, but because they were never visible in the first place.

IDORs themselves aren’t a new lesson, everyone already knows to check for them. The actual takeaway here is narrower and more useful: the reachable surface of an API is different depending on which client you’re looking at, and mobile apps routinely call endpoints a web tester would never even know exist. Proxying mobile traffic isn’t an optional extra step on programs with a mobile client, it’s often the only way to find the endpoints nobody’s reviewed yet.