How a Simple Analysis Revealed an IDOR That Exposed User PII

So, what exactly is an IDOR (Insecure Direct Object Reference)?

IDOR is an access control vulnerability in which the application uses direct references to internal objects without validating whether the user has authorization to access them, allowing unauthorized access to other users' resources.

The reconnaissance phase

During my testing on bug bounty programs, I usually run a few crawler stages (which I'd argue is one of the most important) before exploration, using tools such as: "waybackurls", "waymore", "otx (alienvault)" and "Virustotal" to gather as much information as possible, because from there, I'm able to identify possible entry vectors. However, something really caught my attention — one of the vectors escalated from a simple analysis into a misconfiguration that chained into a PII IDOR. It involved a third party, but the impact was spot on.

The misconfiguration

While collecting data with "virustotal", something caught my eye: https://virustotal.com/vtapi/v2/domain/report?apikey=<YOUR-API>&domain=app.target.com note: you can create an account to get your API key, which increases the tool's output.

https://target.com/s-verification/<UUID>?...

When accessed, it returned the following message (even after refreshing the page, it remained static): "Your profile has been verified"

I found it pretty suspicious because it was a verification that was performed when accessing the endpoint, but obviously, if I reported that as is, I would surely get an "N/A" or "Informative". So here comes the most important part: "what if I observe what's being sent under the hood?" That's when I used Burp to access the endpoint and saw everything that was being passed along, and with that I discovered the following — it sent a GET request with an ID and the response returned:

GET /resources/applicants/<ID>/one

A massive PII leak, including passport number, photo URL, and other personal information. And now comes the main point: it was a third-party API (*.sumsub.com) that handled the account validation. How do I argue this? Considering that the scope stated:

Third‑Party: ... or external services without direct impact on our users data.

The IDOR

Now comes the importance of trying to argue for an escalation, even when limited to a constrained scenario. That's when I thought: would all those links indexed by the crawlers with the UUID return different account information? I ran the tests again, accessing each one of them, and there were more than 40 — all vulnerable, just by swapping the UUID (typically, IDORs with UUIDs aren't accepted, unless you find a way to obtain them, and in this case it was via the crawler). They returned information about each user indexed there, so not accepting this vulnerability would put at risk every user indexed and their documents.

Conclusion

This writeup shows the importance of analyzing the requests that go on under the hood — it can be just as important as directly accessing a URL that leads to a possibly limited access. When tested thoroughly, it can reveal other points (even if out of scope) that were leaking data, in this case a misconfiguration of the sumsub API, where there were no authentication mechanisms based on tokens or session cookies whatsoever.

This vulnerability was rewarded with a €975 euro bounty. It was rated as medium severity because it depended on the crawling tool and on the UUID, but regardless, the impact is far greater than a simple technical evaluation level.

Connect with the author for networking and more technical content: LinkedIn | X/Twitter