Introduction

I wasn't looking for anything specific, just exploring websites for research and practice. Eventually, I came across a donation platform. I created an account and started poking around and found some interesting stuff: a critical IDOR vulnerability that exposed personal details of every user and allowed me to completely take over their accounts.

What is IDOR?

It's an access control vulnerability that occurs when an application exposes an internal identifier (like user_id=123) but fails to verify that the logged-in user actually owns or is authorized to access that object. What makes IDOR dangerous is also what makes it common: it's a very simple bug. You don't need advanced exploitation skills or deep technical knowledge to abuse it, often it's just a matter of changing a number in the request. Despite being simple, IDORs are still seen frequently in real-world applications and can lead to severe consequences such as mass data leakage or full account takeover.

Example:

GET /api/profile?user_id=1001   ← your account  
GET /api/profile?user_id=1002   ← victim's account (if no checks)

If the server doesn't verify ownership, that second request leaks another user's information.

First Observations

Once I registered, I had access to a profile page. Every time I refreshed, I noticed a request going out to fetch my profile data:

POST /backend/api/customer-profile?user_id=46328&page=profile

The user_id came from a cookie that was set at registration. Even worse, it wasn't a UUID or any kind of random string, just a simple incremental integer. This looked interesting, what if I changed the ID?

I modified the request and replaced my ID with another number. Immediately, the server responded with a different user's full profile:

The response exposed the user's first & last name, email address, phone number, address, date of birth, social ID, OTP and device tokens, profile image, transaction history, hashed password and more.

At this point, I realized this was more than a simple bug, it was a critical IDOR exposing sensitive data.

Writing a Quick Dump Script

To make sure this wasn't a one-off, I wrote a short script that looped through IDs and stored the responses. Every request returned a new user profile. I didn't go overboard, just enough samples to prove the issue and prepare evidence for later disclosure.

Playing With Profile Pictures

Next, I explored more of the profile features. When I uploaded a profile picture, I noticed the request body also included my user_id.

Deleting a profile picture also was done with the user_id:

POST /backend/api/delete-customer-photo

with the body:

{"user_id":46328}

I wondered what would happen if I deleted another user's photo. I tried it in Postman, targeting a random user ID. The request returned 200 OK. When I fetched that user's profile again, their picture was gone.

This confirmed it: the vulnerability wasn't just leaking data, it allowed me to modify other users' accounts.

Full Account Takeover

The real jackpot came when I tested the update profile feature. When I changed my own details, I saw a request like this:

POST /backend/api/update-customer-profile

with the body:

{
    "user_id": 46328,
    "fname": "abcd",
    "lname": "abcd",
    "email": "test@test.com",
    "phone": "123456789",
    "address": "abcd",
    "country": "abcd",
    "country_code": "ab",
    "city": "abcd",
    "gender": "male",
    "dob": null
}

Again we can see it uses my ID in the request body, so I asked myself: what if I swapped the user_id with someone else's and changed their email to mine?

I tried it. The server responded with 200 OK. And it worked, I had just replaced another user's email address with my own.

From there, it was game over:

1. I used the Forgot Password feature on the website.
2. The reset email landed in my inbox.
3. I set a new password.
4. I logged in as the victim.

This confirmed the worst-case scenario: a critical IDOR that led directly to full account takeover.

Of course, to stay responsible, I changed the email back to the original and stopped testing any further.

Why This Matters

The impact was huge:

Data Leakage: Exposure of personal details for every user. Unauthorized Modification: Ability to delete or change other users' data. Account Takeover: Any account could be hijacked through an email change and password reset. Trust and Compliance Risks: For a donation platform handling sensitive user information, this could be catastrophic.

Potential Real-World Impacts

If exploited by a malicious actor, this vulnerability could enable:

Targeted Phishing / Smishing / Social Engineering: Exposed emails, phone numbers, and addresses can be used to send highly convincing scam messages or impersonate the organization.

Identity Theft: Social IDs, DOB, and full names could be combined to create fake identities or abused in KYC/fraud attempts.

Impersonation: Attackers who hijack accounts could pose as legitimate donors or recipients, damaging trust.

Defacement / Profile Manipulation: Attackers could delete profile photos or alter personal information, causing reputational harm to users.

Mass Data Exfiltration: Automated enumeration could harvest the entire user database (PII at scale), which could later be leaked, sold, or abused.

Reporting the Vulnerability

With enough proof in hand, I prepared a report. I included screenshots of the requests, responses, and proof of account takeover, then sent it to the site's support team. I made sure not to exploit further, and I restored the account that I modified.

Conclusion

What started as a small curiosity, changing a number in a request, turned into a critical IDOR leading to full account takeover and data leakage.

This was my first account takeover discovery, and it taught me how devastating "simple" bugs can be. IDORs are still everywhere, and if left unchecked, they can compromise entire platforms.