During bug hunting, I discovered an IDOR vulnerability that allowed unauthorized deletion of resources across accounts within the same tenant. A low-privileged user could craft a DELETE request targeting another user’s resource ID, successfully bypassing authorization controls. Despite role-based access being enforced on the frontend, the backend lacked proper checks. This exposed sensitive functionality to users who shouldn’t have access to it. The issue was responsibly reported and rewarded with a $500 bounty.
About the Application #
Due to responsible disclosure policies, I cannot reveal the actual target domain, so let’s refer to it as example.com. This platform is a vendor-facing web application designed to facilitate business partnerships. It enables organizations to manage third-party vendors through a structured onboarding process. Core features include user invitation, account activation, role assignment, and retail ID management. Administrators can create custom roles with granular permissions, controlling access to various modules and operations across the portal.
The application is designed to support multiple organizations, each operating within its own isolated tenant. This means that vendor interactions and permissions are scoped strictly within each tenant’s boundaries. However, I discovered a vulnerability that allowed unauthorized actions within the same tenant specifically, between users belonging to the same organization due to improper access control. As a result, even a low-privileged user could perform actions intended only for an administrator.
What is IDOR? #
IDOR (Insecure Direct Object Reference) occurs when an application uses user-supplied input to access objects like database records, files, or URLs, without properly validating if the user has permission to access those objects. This means an attacker can manipulate identifiers (such as IDs in URLs or API calls) to view, modify, or delete data that belongs to other users. It’s a critical flaw because it breaks the principle of access control, allowing unauthorized actions within the same application or tenant environment.
How I Discovered the Bug? #
During my testing of the application’s functionality, I focused on the management of retail chain IDs linked to user accounts. Here’s how I uncovered the vulnerability:
- Account Setup and Role Exploration: First, I created two user accounts with different privilege levels, one with full permissions and another with only read permission. This helped me understand how the application enforced access control based on roles.
- Understanding the Delete Endpoint:
I identified an API endpoint used for deleting retail chain IDs:
DELETE https://example.com/ssoapi/vendorRetailChain/delete/{id}. The endpoint accepted a 4-digit numeric ID as a path parameter to specify which retail ID to delete.
DELETE /ssoapi/vendorRetailChain/delete/6987 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64)
Accept: */*
Content-Type: application/json; charset=utf-8
Tokenwpapi: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...[truncated token]...
Content-Length: 11
{"id":6987}
- Testing Authorization Controls: I tested the delete operation from the high-privilege account successfully, confirming that the endpoint worked as intended for authorized users. Next, I captured the delete request using a proxy tool like Burp Suite.
- Token and Permission Manipulation: Then, I logged into the low-privilege account, captured its authentication token, and replaced the high-privilege account’s token in the captured delete request with the low-privilege one. I sent the request again without modifying the ID.
- Result and Confirmation: The delete request succeeded even with the low-privilege token, meaning the system did not properly verify whether the user had rights over the specified ID and it became clear that any retail ID could be deleted regardless of account ownership. This confirmed a classic IDOR vulnerability, the application relied only on the ID parameter for authorization instead of enforcing strict ownership checks, allowing cross-account unauthorized deletions.
Why This Flaw Matters? #
This IDOR vulnerability allows a low-privileged user to delete critical data belonging to other users by manipulating a simple numeric ID in the API request. Because the ID space is small and predictable, an attacker can easily enumerate IDs and perform unauthorized deletions at scale. Such unauthorized actions compromise data integrity, disrupt normal operations, and can lead to significant business and reputational damage. In environments where data access controls are crucial, this flaw undermines the fundamental principle of authorization and user isolation, making it a high-risk security gap.
How I Reported the Bug and Earned a $500 Bounty #
After uncovering the IDOR vulnerability, The next step was to communicate it clearly to the security team. I took my time to gather all the necessary evidence, from detailed screenshots to carefully captured HTTP requests, to ensure there was no doubt about the issue or how to reproduce it.
I submitted the report on HackerOne, making sure to explain the impact and the exact steps to trigger the vulnerability. The team appreciated the thoroughness and clarity, which helped them verify and prioritize the fix quickly. A few days later, I received confirmation along with a $500 bounty as a reward for this bug.
Tips for Bug Bounty Hunters: Approaching IDOR Bugs #
When looking for IDOR vulnerabilities, it’s essential to understand how the application manages user-specific data and permissions. Start by identifying endpoints that handle resources tied to user IDs or other identifiers, such as account details, orders, or settings. Pay particular attention to APIs that accept parameters like numeric IDs or strings that seem sequential or guessable. Using proxy tools like Burp Suite or OWASP ZAP, intercept requests and try manipulating these identifiers to see if you can access or modify data belonging to other users. Don’t forget to test across all HTTP methods, including DELETE and PUT, which might expose destructive operations. Monitoring the application’s response for errors or success messages can help confirm if authorization checks are properly enforced.
Another important step is testing with multiple user roles or privilege levels. Create accounts with varying permissions to see if lower-privileged users can perform actions meant for administrators or higher-privileged users. Role management functionality is often a weak point that attackers exploit to escalate privileges or access sensitive data. IDOR bugs often require enumerating IDs or chaining different endpoints to achieve unauthorized access. Finally, provide clear and reproducible steps in your reports along with proof-of-concept requests to help triagers and developers to quickly understand and fix the issue, increasing your chances of earning a bounty.
Mitigation: How to Prevent IDOR Vulnerabilities #
- Always enforce robust server-side authorization checks that validate whether a user has permission to access or modify the requested resource. Never rely solely on client-side controls or obscured identifiers.
- Replace predictable resource IDs with non-sequential, hard-to-guess identifiers such as UUIDs or hashes, making it significantly harder for attackers to enumerate valid resources.
- Implement a comprehensive role-based access control (RBAC) system and regularly review API endpoints to detect and fix any improper access permissions before they can be exploited.
Final Thoughts #
This bug is a classic reminder that even in well-structured applications, backend authorization should never be taken for granted. Just because a feature is hidden in the UI doesn’t mean it’s secure. IDORs like this may seem simple, but their impact can be serious especially when they let low-privileged users perform high-privilege actions. Hunting bugs is all about staying curious, having patience and checking what happens behind the scenes.
If you found this write-up helpful, don’t forget to follow me on X: medusa0xf