Objective

Access another user's private delivery information by exploiting an IDOR vulnerability in the booking tracking endpoint.

Recon

Logged in as a regular user on Galaxy Dash, an intergalactic delivery management app. The dashboard showed my deliveries, organization info, and permissions.

None

While exploring the app with Burp Suite running, I checked the Target > Site Map and noticed an interesting endpoint: GET /api/network/status. Sending a request to it returned a list of active deliveries — I could identify my own booking in the response, but there was also a second tracking ID that didn't belong to me. The endpoint was exposing other users' delivery data alongside mine.

None

Exploitation

Step 1 — Extract the other user's tracking ID

From the /api/network/status response, I grabbed the tracking ID that didn't belong to me:

afedeb56-f7eb-4133–9829-e71bfe1b6d9c

Step 2 — Access their booking directly

Plugged the ID into the booking tracking endpoint:

GET /api/bookings/afedeb56-f7eb-4133–9829-e71bfe1b6d9c/tracking

Response: 200 OK — returned the full delivery record including cargo details, pricing, origin/destination, and the flag buried in cargo_description.

"cargo_description": "bug{JHRy7cLikT2VuW3AwgV8J5yjrxZalIE4}"

None

✅ Flag captured.

What Didn't Work

  • Since both deliveries appeared in /api/network/status, I first assumed the second one was also mine. Checking the booking details confirmed it belonged to a different user entirely.

Key Takeaway

Two vulnerabilities chained here: the /api/network/status endpoint leaked other users' tracking IDs alongside my own, and the /api/bookings/{id}/tracking endpoint had no ownership check — it returned full data to anyone with a valid ID regardless of who owned the booking.

Fix: shared network endpoints should never expose other users' tracking IDs, and every object access request should verify the requester actually owns that object.

OWASP: A01 Broken Access Control — Insecure Direct Object Reference