The mobile app wasn’t hacked.
The API was trusted too much.
That trust exposed user data—quietly, consistently, and at scale.
This is one of the most common causes of mobile data leaks today.
What Actually Happened
The mobile app used an API endpoint like this:
GET /api/v1/user/profile?id=12345
The app assumed:
1. The user is authenticated
2. The user only requests their own data
The API never enforced that assumption.
The Core Problem: Broken Object Level Authorization (BOLA)
The API checked:
“Is the user logged in?” ✅
But it did not check:
“Does this user own this data?” ❌
So when an attacker changed the ID:
GET /api/v1/user/profile?id=12346
They received another user’s data.
No malware.
No exploit kit.
Just logic abuse.
Why This Went Undetected
From the server’s perspective:
1. Requests looked legitimate
2. Tokens were valid
3. No rate limits were hit
Logs showed:
“Authenticated user accessed profile endpoint”
Nothing screamed “attack”.
Real Data Exposed (Typical)
Leaks of similar nature have resulted in leaked data such as:
1. Full names
2. Mailing Address
3. Mobile Number
4. Past Orders/Medicines Purchased
5. Partial Payments made to the dealer
6. Internally Assigned User ID’s
No password was needed to do severe damage with the exposed information.
How Attackers Discover This
Step One: Analyze App Traffic
Attackers use tools like Burp Suite or MITMproxy to proxy the mobile application. They are looking for the following:
1. Identifiers contained within URLs
2. Identifiers contained within JSON data
3. Values that are either sequential or can be predicted.
Step Two: Change Requests
An example of an initial request would be: If the API sends us back a data file. If yes, it means we can assume we found a leak.
Original request:
GET /api/v1/orders?user_id=8821
Authorization: Bearer eyJhbGci...
Modified request:
GET /api/v1/orders?user_id=8822
Authorization: Bearer eyJhbGci...
If the API responds with data → leak confirmed.
Step Three: Automatically Find Additional Identifiers
After confirming that the first leak exists, the attackers can take this process further and automate the process of finding additional identifiers.
for i in {8000..9000}; do
curl -H "Authorization: Bearer TOKEN" \
https://api.app.com/v1/user/profile?id=$i
done
The leak has now become a systematic process.
Why Mobile APIs Are Especially Vulnerable
The vulnerability of mobile applications is attributed to the following factors:
1. Mobile applications do not allow for the hiding of API endpoints.
2. Tokens issued to mobile applications are stored on the device.
3. API reusability is often determined more by speed than by security.
If a mobile application's API trusts its clients, that API has failed.
Common tools used for both defensive and testing procedures:
Testing and discovery:
1. Burp Suite for manipulating API requests
2. Postman for replaying and testing API authorization logic
3. OWASP ZAP as an automated method to scan APIs
Detection and monitoring:
1. Reviewing gateway logs of APIs to identify unexpected users accessing API objects
2. SIEM rules to identify enumeration of unique user/ID combinations
3. Behavior analytics to identify instances of many unique IDs being accessed by one user.
Simple Code Example: The Vulnerable Logic
❌ Vulnerable API logic:
@app.route("/user/profile")
def profile():
user_id = request.args.get("id")
return get_user_profile(user_id)
✅ Secure version:
@app.route("/user/profile")
def profile():
user_id = request.args.get("id")
if user_id != current_user.id:
return "Unauthorized", 403
return get_user_profile(user_id)
Authentication alone is not authorization.
How This Could Have Been Prevented
Simple controls that stop this entirely:
1. Object-level authorization checks
2. UUIDs instead of incremental IDs
3. API rate limiting
4. Access logs reviewed for anomalies
5. Security testing before release
None of these are complex.
They’re just often skipped.
Why This Matters to Business
One API flaw can lead to:
1. Mass data exposure
2. Regulatory fines
3. App store removal
4. Brand trust damage
And the worst part?
The app still “worked perfectly”.
Key Takeaways
1. Most mobile data leaks are logic flaws
2. APIs must never trust the client
3. Auth ≠ authorization
4. One endpoint can expose millions of records
5. Testing APIs is more important than testing UI
This isn’t advanced hacking.
It’s missing a single security check.
