Exploiting IDOR in a Support Portal Chatbot

Sometimes, I avoid testing support or help portals, assuming they might be hosted on third-party platforms like Jira or Zendesk, to save time and effort and avoid dups. However, after this incident, I’ve learned never to make that assumption again.

Out of curiosity I randomly found this subdomain on a program which had a support portal. The domain looked something like support.xyz.com

Based on my reconnaissance, this particular portal didn’t show any fingerprints indicating it was built on third-party software services. The portal featured a typical chatbot, and once again, I assumed the chatbot must be another third-party service.

I just had the curiosity to check so i just started a chat with the ChatBot. To start a chat the User must input the Name, Email and the Service Account Number which looked like below

Chatbot UI

Since I already had an account on the main portal, I tried using that same service account name here. It worked, and I was successfully verified as a user. Initially, I tested with typical payloads, but they didn’t yield any results.

While reviewing my Burp Suite HTTP history, I noticed a few API calls labeled with endpoints like Authenticate, Verify, and User like below

Burp History

This made me pause and reconsider—it didn’t seem like a typical chatbot setup. Usually, chatbots rely on WebSockets for real-time communication. However, when I checked the WebSocket history in Burp Suite, there were none, which raised further suspicion.

Upon further inspection, my suspicion was correct — the chatbot was developed by integrating their API. Every time I entered my service number, it authenticated the input and generated a temporary access token to access thier API.

Upon further inspection, my suspicion was correct — the chatbot was developed by integrating their API. Each time I entered my service number, it authenticated the input and generated a temporary access token to interact with their API.

Digging deeper, I discovered that the /api/v2/user/110022 endpoint returned a response containing service account details. The response looked something like this:

HTTP Response

Then, I ran Intruder to brute force the User IDs, and it returned numerous records containing customer information associated with each ID. This confirmed that the endpoint was vulnerable to an IDOR (Insecure Direct Object Reference) vulnerability, exposing sensitive user data.

One additional test I always perform in such scenarios is to check for missing authentication controls. This helps identify if the endpoint is accessible without any authorization, making the impact even more severe. To test this, I removed the authorization token and sent the following request:

Removing Auth Token

To my surprise, the endpoint returned the full user details even without an authentication token. This indicated a critical security flaw, as the API allowed unauthenticated access to user data.

No Rate Limiting: The API lacked rate-limiting mechanisms, which allowed brute-forcing of User IDs without restrictions.Predictable User IDs: The User IDs were sequential, making it trivial to enumerate all users in the system.Exposed Sensitive Data: The response included Personally Identifiable Information (PII), such as names, email addresses, account statuses, and roles.

Once reported, the team confirmed that the API was deprecated but had been overlooked during decommissioning, leaving it exposed. They acknowledged the oversight and quickly took action to remove the vulnerable endpoint.

This highlighted the importance of thoroughly auditing all legacy systems and APIs, even those deemed obsolete, to prevent security risks from lingering unnoticed.