Hey Hackers, I am Parth Narula. A penetration tester, bug hunter, red teamer and overall a security researcher. I live for those moments where a bit of out-of-the-box thinking cracks open a critical vulnerability.

This started during a penetration test of a housing platform. Unavailable listings hid the Send message button, while available ones worked as expected. But a quick look at the request in Burp showed a single parameter that changed everything.

Let's assume the target as redacted , just like any housing rental application.

I had two advertisements under my account (one is Online and another is Offline). Interestingly, both advertisements had the same name :)

The first advertisement was named Test 12 test with an iguana picture. This one was online and available for rent. (I was also testing EXIF metadata ^_^).

The second advertisement was also named Test 12 test, but this one had a Starbucks picture and was offline, meaning it was not available for rent. (If I clicked the "FOR RENT" button on it, it would become online and available again.)

Now, when I tried visiting the publicly accessible URL of the offline advertisement: https://redacted/best/test_12_test/109

It loads successfully, but at top right, It showed an error saying:

"This housing is occupied...."

Nothing serious. Totally expected. Everything looked normal so far.

After that, I visited the advertisement that was available for rent: https://redacted/best/test_12_test/107

Here, I noticed something interesting. This page had an option called "Go to Message", which was not present on the offline advertisement.

Okay, fair enough.

So I clicked on "Go to Message" to message the landlord and intercepted the request in Burp Suite. At first glance, it was a completely normal request. But one thing immediately caught my attention.

There was a parameter called advertisement_id=107 This ID clearly belonged to the online advertisement (yes, the iguana picture one).

As expected, I was able to send a message to the landlord of the available advertisement without any issue.

But this is where curiosity kicked in. I started wondering…

What if I change this advertisement_id to the one that belongs to the offline advertisement?

We already know that advertisement IDs were visible directly in the URL, and they were sequential and incremental, which meant they could be easily guessed or brute-forced.

So I decided to change the value of advertisement_id from 107 → 109 and sent the request again.

I was redirected to the chat interface.

I was able to successfully message the landlord of an advertisement that was not available for rent. In other words, the backend never validated whether the advertisement was online or offline before allowing the message action.

To confirm the impact, I did some additional testing using Intruder and was able to message multiple landlords whose advertisements were not available for rent.

This confirm the presence of IDOR vulnerability.

Lessons Learned

• Always test backend behavior, not just what the UI allows or blocks
• Sequential and predictable IDs are a huge red flag, never ignore them
• Hidden buttons do not mean hidden functionality
• Curiosity is key. One parameter changing often leads to the full bug

I hope you learn something new. Follow for more amazing articles and give claps if you like this one :)

Need expert pentesting services? visit https://scriptjacker.in or let's collaborate on your next project! 🤝

Want to learn from my experiences? Check out my articles on https://blogs.scriptjacker.in