Case UC-11 · OWASP M3 Insecure Authentication/Authorization

Broken object-level authorization in an app API

An API returned records based on a client-supplied identifier without checking ownership, letting an authenticated user read other users' data by changing a number.

This article documents a representative, anonymised mobile application security case. It describes the weakness, why it matters to a business, how Mobexa detects it, and how to remediate it. No specific application, company or individual is identified.

1 Context

The app's API accepted a client-supplied object identifier and returned the corresponding record without verifying that the authenticated user owned it. Authorization was assumed from possession of a guessable identifier rather than enforced on the server.

2 What the research team found

By varying an identifier in an authenticated request, the team observed records belonging to other accounts being returned. The check that should tie each object to its owner was performed on the client, or not at all on the server.

3 Why it matters

Broken object-level authorization is among the most damaging and most common API flaws: a logged-in user can enumerate and read other users' data at scale. It needs no special tooling, only changing a number, and it scales to the entire dataset behind the endpoint.

4 How Mobexa surfaces it

Mobexa exercises authenticated API flows, varies object references and roles, and detects responses that disclose data the requesting identity should not reach, reporting under M3.

5 Remediation

Enforce object-level authorization on the server for every request, derive ownership from the session rather than the request payload, and use unguessable identifiers as defence-in-depth.

6 Standards mapped

Table 1. Frameworks and references for this case
FrameworkReference
OWASP Mobile Top 10 (2024) M3 Insecure Authentication/Authorization
CWE CWE-639 Authorization Bypass Through User-Controlled Key
OWASP MASVS MASVS-AUTH
authorizationapiidor

Documented by the Mobexa research team. This case is anonymised and provided for educational use; the mapping references the OWASP Mobile Top 10 (2024).