How I got access to an IDOR that exposed PII for 6.4 million users

Nov 9, 2025

How I got access to an IDOR that exposed PII for 6.4 million users

This blog was originally published here by Rohit Tiwari (Dedrknex)

Before starting the article i need to make something very clear am using the target as example.com due to obvious reasons. Our target has a pay and view bill processes.

Introduction

At first glance the target looked secure. The site required an email or mobile number to authenticate, sent an OTP, and had the reassuring little details security teams love to show in slides.

I was reading a Medium writeup about IDORs and thought — why not hunt for one myself? What started as casual curiosity quickly became a full-blown incident: an insecure direct object reference (IDOR) that allowed access to sensitive transaction data and personally identifiable information (PII) across millions of accounts.

Below I tell the story: what I found, how I validated the issue (safely), the scale of the exposure, how I reported it, and the lessons every developer and security team should take from this.

• • •

The setup — a secure-looking surface

From the outside example.com looked reassuring:

OTP login via email or mobile.
A polished dashboard.
An in-browser PDF statement/invoice viewer that felt production-ready.

Those surface signals matter — they make users feel safe. But I’ve learned never to trust the surface alone. Authentication (you are who you say you are) and authorization (you’re allowed to access what you requested) are different problems. So I proxied my traffic with Burp, mapped endpoints, and started cataloguing the app’s API calls.

• • •

The moment the morning changed

Most things behaved. Pages rendered for the logged-in user. Controls looked guarded. Then I found an endpoint that returned monthly prepaid statements. It looked ordinary:

GET /pdfEngine/v2/prepaidStatement?consNo={consumer}&month=April&year=2025

On the UI the flow looked correct: users fetched their PDFs and viewed them in the browser. But the API’s behavior told a different story. The server returned statement data based on client-supplied parameters — and crucially it didn’t verify that the caller actually owned the requested resource. That missing server-side ownership check is the textbook definition of an Insecure Direct Object Reference (IDOR).

I stopped probing there. I didn’t harvest data. I didn’t take screenshots containing real PII. I documented what I observed and planned a responsible disclosure.

Why this was worse than “just an IDOR”

A missing check is problematic — but a few compounding factors made this one severe:

Data richness: Returned statements included full names, phone numbers or emails, billing addresses, and transaction summaries. That’s excellent fodder for targeted phishing, impersonation, or identity fraud.
Enumerable surface: The parameters were manipulable and identifier patterns made enumeration feasible.
Scale: By non-destructive sampling of API behavior (never downloading PII, only observing response patterns), I conservatively estimated the affected pool at ~6.4 million users.

When sensitive fields, enumerability, and scale collide, the risk goes from theoretical to urgent.

• • •

How I validated — responsibly and quietly

I started gathering all the proofs including screenshots
Request and response
Redacted any user personal data
Made a report and submitted to the organization

From this point, things started to get even more interesting. After confirming the vulnerability and documenting everything responsibly, I decided to do the right thing — report it directly to the organization.

But here’s where I hit a roadblock: the organization didn’t have any responsible disclosure or bug bounty program. No dedicated security contact, no disclosure email, not even a basic policy page. Just a “Contact Us” form buried somewhere on their site.

Still, I believed it was important to try. I crafted a detailed, redacted and professional vulnerability report, clearly mentioning the type of issue (IDOR), the potential exposure of millions of users’ personal information, and the urgency of fixing it.

I submitted it through their general contact form and even followed up through support channels — but days turned into weeks, and weeks turned into silence.

Not a single acknowledgment. No “thank you,” no “we’re looking into it,” not even a bot-generated ticket confirmation. At this point, it was clear that the organization either didn’t understand the gravity of the situation or was simply ignoring it.

• • •

Escalating to CERT-In

Since the affected application was Indian-based and dealt with critical consumer data, my next responsible step was to escalate the issue to CERT-In (Indian Computer Emergency Response Team).

CERT-In is the national nodal agency for cybersecurity incidents in India — they act as an official coordinator between researchers and organizations when vulnerabilities pose risks to users or public systems.

I sent them a well-documented report, which included:

A redacted version of the vulnerable endpoint (/pdfEngine/v2/prepaidStatement?...)
A clear explanation of how the missing server-side authorization led to exposure
The potential impact, including an estimate of affected users (~6.4 million)
Suggested remediation steps (authorization checks, ID randomization, redaction, etc.)

Within a few days, I received an acknowledgment from CERT-In confirming that my report was under review. They later reached out to the concerned organization, verified the vulnerability, and worked with them to patch the issue securely.

• • •

The outcome

A few weeks later, CERT-In confirmed that the vulnerability had been remediated successfully. The organization quietly fixed the authorization issue and closed off the exposed endpoint.

Shortly after, I was honored to receive a Hall of Fame mention from CERT-In for my responsible disclosure and contribution to protecting user data.

It felt surreal — what started as a casual IDOR test on a random afternoon had ended up preventing a massive data exposure that could have compromised millions of users’ sensitive information.