One of the most common and damaging mobile app vulnerabilities is not in the app at all, it is in the API behind it. If your backend returns an object based on an ID in the request without checking that the requester is actually allowed to access that object, anyone can change the ID and read someone else's data. This is IDOR, also called broken object level authorization, and it is the top API security risk. The mobile app showing each user only their own data does not help, because an attacker talks to the API directly. Here is what it is and how to prevent it.
Short answer
IDOR (insecure direct object reference), known as broken object level authorization (BOLA), is when an API returns or modifies an object based on an identifier in the request without verifying that the authenticated user is authorized for that specific object. Per OWASP, it is the top API security risk: an attacker simply changes an ID, such as a record number in the URL, and accesses another user's data. It affects mobile apps because the app talks to an API, and an attacker can call that API directly regardless of what the app's UI shows. The fix is to enforce object-level authorization on the server for every request, confirming the user can access the specific object, not just that they are logged in.
What you should know
- IDOR is broken object-level authorization: the API does not check object ownership.
- It is the top API risk: changing an ID exposes other users' data.
- The vulnerability is server-side: the API, not the app, must enforce it.
- The app's UI does not protect it: attackers call the API directly.
- Authenticated is not authorized: being logged in is not the same as being allowed.
What is IDOR / BOLA?
It is a missing authorization check on a specific object. APIs expose objects, an order, a message, a profile, by an identifier, so a request like getting a record by its number is normal. The vulnerability appears when the server returns or changes that object based only on the ID and the fact that the caller is authenticated, without checking that this particular user is allowed to access this particular object. An attacker who is a legitimate user of the app can then change the ID in the request, to another record number, another user's identifier, and the server hands back data that belongs to someone else. The flaw is not that the ID is visible; it is that the server trusts the ID without an ownership or permission check. Being authenticated proves who you are, not what you are allowed to access, and conflating the two is the root of IDOR.
Why are mobile apps affected?
Because the app is just a client of an API an attacker can call directly. The table shows the gap.
| Assumption | Reality |
|---|---|
| The app only shows users their own data | The API can be called directly, bypassing the app |
| The ID is hidden in the app | The ID is in the request and can be changed |
| The user is logged in, so requests are safe | Authentication is not per-object authorization |
| Client-side checks restrict access | Client checks are advisory; the server must enforce |
The core misunderstanding is treating the mobile app as the security boundary. The app might only ever display the current user's records, but the requests it sends go to an API, and an attacker can inspect those requests and replay them with a different ID using ordinary tools. So no matter how the app behaves, if the API does not enforce object-level authorization, the data is exposed. The app's UI is convenience; the server is the boundary.
How do you prevent it?
Enforce object-level authorization on the server, for every request. On each request that accesses an object by ID, the server must verify that the authenticated user is permitted to access that specific object, by checking ownership or a permission rule, and reject the request otherwise, not merely confirm the user is logged in. Apply this consistently across every endpoint, since IDOR usually hides in the one endpoint that forgot the check. Do not rely on the client to restrict access, and do not treat an unguessable or random identifier as the control; hard-to-guess IDs are reasonable defense-in-depth but are not a substitute for an authorization check, since IDs leak. Where you use a backend with row-level security, configure it so each query is scoped to the requesting user. The principle is that every object access is an authorization decision the server must make.
What to watch out for
The first trap is assuming the app's UI protects the data, when an attacker calls the API directly with a changed ID. The second is checking only authentication, being logged in, rather than authorization for the specific object. The third is relying on unguessable IDs instead of an actual ownership check. IDOR is a server-side flaw, so it is enforced and tested on your backend rather than found by inspecting the binary, but a pre-submission scan such as PTKD.com (https://ptkd.com) reads your app against OWASP MASVS and surfaces the API endpoints your app calls, which is a useful inventory of the surface where object-level authorization must be enforced and verified server-side.
What to take away
- IDOR, or broken object level authorization, is an API returning or modifying an object by ID without checking the user is authorized for that specific object, and it is the top API security risk.
- It affects mobile apps because an attacker can call the API directly with a changed ID, regardless of what the app's UI shows.
- Prevent it by enforcing object-level authorization on the server for every request, confirming ownership or permission, not just that the user is logged in.
- Do not rely on the app or on unguessable IDs, and use a pre-submission scan such as PTKD.com to inventory the API surface where server-side authorization must hold.
