While hunting on a public program on Bugcrowd, I discovered an interesting IDOR vulnerability in a SaaS platform that I'll refer to as redacted.com.
The application had an internal API endpoint used for loading customer support tickets. During testing, I noticed that the endpoint trusted a static organization header called Pid instead of properly validating the user session.
After some testing, I found that anyone with a valid Pid value could access customer ticket data even without authentication
Vulnerable Request
GET /api/customers/{customer_id}/recent_tickets/
Pid: <organization-id>Reproducing the Issue
- Login to the application and open the support ticket section.
- Capture the ticket API request in Burp Suite.
- Remove all cookies/authentication headers and replay the request.
4. Modify the customer_id or Pid value to access other customer/organization ticket data.
Impact
This vulnerability allowed:
- Unauthenticated access to customer support tickets
- Cross-organization data exposure
- Access to sensitive customer conversations
- Persistent access for removed users
- Mass data extraction due to missing rate limits
Since the Pid value remained static, even users removed from the organization could continue accessing ticket data if they still possessed the header value
Reporting Experience
The report was initially rejected as non-applicable. After multiple follow-ups and additional impact clarification, the issue was eventually reproduced, triaged, and rewarded with a $$$ bounty.
Conclusion
This issue happened because the application relied entirely on a user-controlled header for authorization instead of validating authentication and organization membership properly.
A small trust issue eventually turned into a valid IDOR and authorization bypass vulnerability.