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 is the story of a shocking IDOR I found in a booking platform payment flow. With one simple change, I could force a payment method that was not even enabled for the service onto a different user's booking.

It started when I was examining the checkout process on a booking platform. I had two different service bookings open in separate browser tabs.

https://REDACTED/booking/checkout/94171965

https://REDACTED/booking/checkout/94171966

The first booking, let's call it Booking 1, had the ID 94171965. For this booking, the available payment methods were Swish and Klarna. The total amount was 1160 SEK. This booking was tied to a specific store created during checkout.

None

When I intercepted the payment initialization request in Burp Suite, it looked like this:

POST /api/swish/payments
Content-Type: application/json

{
  "type": "booking",
  "id": 94171965,
  "giftcards": []
}
None

Now, in another tab, I had Booking 2 for a completely different service and store. This booking had the ID 94171966 and a total of 200 SEK. Its available payment methods were Card and Giftcard. Noticeably, Swish and Klarna were not presented as options here.

None

This discrepancy immediately sparked my curiosity. What would happen if I tried to use the payment flow from one booking on another?

I took the request from Booking 1 and simply changed the id parameter from 94171965 to 94171966 (the ID from Booking 2). I forwarded this modified request.

None

The server responded with 201 Created. The response included a payment ID and even a QR code for Swish payment!

None

This was a clear and critical issue. I had successfully initiated a payment for Booking 2 using the payment methods tied to Booking 1 at /api/swish/payments. Even more significant, I was able to pay with Swish . A method that was never offered or available for Booking 2's service and store.

None

It broke the core business logic that dictated which payment options should be available for specific services and stores.

Lessons Learned

Treat Every Object Reference as a Potential Vulnerability Any ID in a request, whether it's a booking_id, user_id, or payment_id, is a potential target for manipulation. Never assume the application will validate it correctly on the backend.

Test State Transitions and Cross Context Requests Security testing must go beyond isolated features. Try to mix contexts, use data from one user's session, one booking, or one product in the flow of another. This is where authorization flaws often hide.

Map All Client Server Interactions Thoroughly document every API call during a complex flow like checkout. Understanding the normal sequence makes anomalous, malicious requests much easier to spot and exploit.

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