How I Earned a $1,000 Bounty by Exploiting a Simple IDOR

How I discoverd IDOR?

While testing the security of a web application, I was looking at the API flow requests generated in login process. The flow was simple Enter the email + password and get logged in.

First Request was sent to /api/sessions/login

Just after logged in a GET request was being sent to /api/users/{id} → Id was basically mapped serial wise eg.. 1 for first user 2 for second user

Everything was normal but that /api/user/id thing attracted me. Next, i simply started messing around the ID just to see how API handle it.

To test it further, I sent the request to Burp Repeater. (Just right click on request and click on sent to repeater) The ID Mapped to my account was 842.

So, I thought the previous person would have been assigned the ID 841…right?

I simply changed it to 841 and boom 💥 I got the other user's details that were mapped to 841.(previous signed up user)

For better Understanding:

The original request looked like this:

GET /api/users/<MY_USER_ID> HTTP/2
Host: <REDACTED>
Authorization: Bearer <REDACTED>

GET /api/users/<MY_USER_ID> HTTP/2
Host: <REDACTED>
Authorization: Bearer <REDACTED>

I changed only the object identifier: (Modified the user id part)

GET /api/users/<ANOTHER_USER_ID> HTTP/2
Host: <REDACTED>
Authorization: Bearer <REDACTED>

GET /api/users/<ANOTHER_USER_ID> HTTP/2
Host: <REDACTED>
Authorization: Bearer <REDACTED>

I wasn't expecting much. Normally, the server should perform an authorization check and return something such as: 403 or reject the request in some other way. Instead, the server responded with: HTTP/2 200 OK The response to this request contained profile information belonging to a different user.

That was the moment the issue became interesting.

Why This Happened ?

The asnwer is Simple: The Authorization Check Was Missing

The server appeared to be correctly authenticating my request because I was using a valid access token.

The problem was what happened after authentication.

The application to trust the user ID supplied in the URL without verifying whether the authenticated account was actually authorized to access that object. (as you can see in above image)

The Impact

Unauthorized Profile Access: An authenticated attacker could access profile information belonging to other users by modifying the user ID.

Potential Wider Impact: Similar authorization weaknesses could potentially affect other API resources, but I did not test or assume that other endpoints were vulnerable.

Verified Impact Only: I reported only the behavior I could safely reproduce and verify, following the principle: don't claim an impact you haven't demonstrated.

Getting The Bounty

Although, this was a Responsible Disclosure Program, i did not expected any bounty just reported it to the program Reporting:

After 2–3 Follow ups, they were able to fix the vulnerability, After fixing they offered me the bounty of $1,000

Note: Sensitive identifiers, personal information, authentication tokens, and infrastructure details have been redacted from this write-up. Testing was limited to what was necessary to validate and responsibly disclose the vulnerability.

Found this helpful? Give it a clap (or 50 — you can!) and share it with someone who's just getting into OSINT. It helps more people find the content.

I'll be sharing more real-world security findings, CTF experiences, OSINT investigations, and lessons learned along the way.

You can also connect with me on LinkedIn to follow my work in cybersecurity, vulnerability research, and OSINT. 🔐💻

Thanks for reading, and happy hunting! 🐞🔐