The “Open House” API: How I Found a Massive IDOR Vulnerability

In the world of bug bounty hunting, we often talk about complex exploit chains or fancy RCEs. But sometimes, the most dangerous vulnerabilities are the ones that are staring you right in the face — the ones where the application basically says, "Sure, help yourself to everyone's data!"

Today, I'm pulling back the curtain on an IDOR (Insecure Direct Object Reference) vulnerability I found that turned a simple user profile endpoint into an open-data buffet.

The "Aha!" Moment

I was doing my usual recon, intercepting traffic with Burp Suite. I was logged into my own test account, just minding my business, watching the login and dashboard requests pass by.

Then, I saw it: GET /api/v1/users/415906.

The server responded with my profile data. My brain immediately switched to "attacker mode." I wondered, What happens if I change 415906 to 415907?

[Insert GIF: A person slowly leaning forward in a chair with a smirk]

I sent the request. The server didn't blink. It didn't ask "Are you sure?" or "Do you own this account?" It just returned the data for user 415907. I felt like I'd just walked into a bank, asked the teller for the keys to the vault, and they handed them over with a smile.

The Proof of Concept (The Fun Part)

I didn't want to just stop at one user. I needed to show the scope of this "open door." I wrote a small bash script to see how deep the rabbit hole went.

1. The Quick Peek

I started by grabbing a handful of IDs just to see if the vulnerability was consistent:

# Brute-force user IDs to confirm data exposure
for id in {415906..415910}; do
  curl -s "https://api.vulnerable-target.com/api/v1/users/$id" \
    -H "Authorization: Bearer $TOKEN" | jq -r '.email // "---"'
done

# Brute-force user IDs to confirm data exposure
for id in {415906..415910}; do
  curl -s "https://api.vulnerable-target.com/api/v1/users/$id" \
    -H "Authorization: Bearer $TOKEN" | jq -r '.email // "---"'
done

The result? A clean list of emails and names — all completely unauthorized. shows exactly what I saw: a perfectly formatted JSON dump of user data that I had no business accessing.

2. The Full Extraction

Once I realized the IDs were sequential, I knew it was game over. I created extract_all_data.sh to scrape everything systematically. Watching the terminal scroll with user after user was like watching a slow-motion car crash of data privacy. As shown in

I successfully pulled thousands of records, including names, emails, and account statuses.

Why This Happens (And How to Fix It)

This is a classic case of "Security by Obscurity" failing miserably. The developers likely thought that since the API was behind an authentication layer, nobody would guess the IDs.

Pro-Tips for Developers:

Never trust the client: The server is the only source of truth. Always check if the authenticated user has the right to access the resource.
UUIDs are your friend: Stop using sequential integers (1, 2, 3…). Using long, random strings (UUIDs) makes it mathematically impossible for an attacker to guess the next ID.
Think like us: Before deploying an endpoint, ask yourself: "If I were a bored hacker with a script, how would I abuse this?"

Final Thoughts

This bug wasn't found through complex fuzzing or specialized tools; it was found by simply questioning the logic of the application.

To my fellow hunters: don't get obsessed with the latest CVEs. Sometimes the best bugs are the ones hidden in plain sight. Keep your eyes open, your terminal ready, and never stop questioning those API requests.

Happy hunting, and stay ethical!

If you enjoyed this write-up, feel free to clap, comment, or connect with me on Linkedin!

Disclaimer: This write-up is for educational purposes only. Always perform security testing within the scope of a bug bounty program and follow responsible disclosure practices.

Linkedin: https://www.linkedin.com/in/alfazhossain/

Bye bye — Allah Hafiz.