# IDOR to delete images from other stores

IDOR in Zomato's remove-active-photo endpoint let any store owner delete another restaurant's photos by swapping photo_ids, since ownership of the photo was never checked.

- Payout: $600
- Severity: low
- Program: Eternal
- Credited: emitrani
- Disclosed: 2018-09-05
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/404797
- Library page: https://bugbountylibrary.com/r/h1%3A404797
- Tags: domain:web impact:integrity kind:bounty platform:hackerone sev:low tech:php vuln:access-control vuln:idor

**Target:** PHP client_manage_handler endpoint (remove-active-photo)
**Root cause:** The handler verified the logged-in user had permission on the supplied res_id but never verified that the supplied photo_ids actually belonged to that res_id, so any authenticated manager could delete arbitrary photos.
**Steps:**
1. Create/own two stores.
2. On store 1 open https://www.zomato.com/clients/manage_photos.php and delete a photo, capturing `GET /php/client_manage_handler?res_id=...&photo_ids[]=...&removable=1&case=remove-active-photo`.
3. Record the `photo_ids[]` value.
4. Log in as store 2, capture the same request with its own res_id and cookies.
5. Replace `photo_ids[]` with store 1's value and send.
6. Observe the target photo is deleted.
**How found:** While testing restaurant-manager endpoints, noticed photo deletion was a GET with a `photo_ids[]` parameter; suspected IDOR, confirmed the ID is exposed on the restaurant's public front page, then validated against a second manager account to avoid deleting production photos.
**Exploitation:** Authenticated store manager sends a GET to the remove-active-photo handler with their own res_id but a victim's photo_id (harvestable from the victim's public store page), deleting the victim's image.
**Insight:** Photo/media IDs are often exposed on public storefront pages, so a delete endpoint that authorizes only the parent resource (res_id) but not the child object (photo_id) is trivially exploitable for targeted deletes.