IDOR Exposure of 6.4 Million Users: A Real-World Breakdown of a Critical Authorization Failure
A deep dive into how a single insecure direct object reference exposed personal and billing data for over 6.4 million users - and how responsible escalation led to a secure fix.
Disclaimer
This article is for educational, defensive cybersecurity purposes only. No sensitive personal data was accessed, harvested, stored, or misused. All validation was performed safely with redacted test data. Disclosure was made responsibly to CERT-In, who coordinated remediation with the affected organization.
Introduction
A secure-looking surface can hide deep architectural flaws. This case study demonstrates how a single missing server-side authorization check - an Insecure Direct Object Reference (IDOR) - exposed personally identifiable information (PII) for an estimated 6.4 million users.
The researcher responsibly escalated the issue through CERT-In after the organization failed to acknowledge the report. The vulnerability was subsequently verified, patched, and recognized with an official Hall of Fame mention.
This article reconstructs the discovery, impact, and reporting flow so developers and security teams can understand why IDORs remain one of the most dangerous and common API vulnerabilities.
Understanding the Application: A False Sense of Security
At the surface level, the target website (referred to as example.com for confidentiality) appeared secure:
- OTP login using mobile or email
- Smooth dashboard UI
- In-browser statement/PDF viewer
- Strong branding, polished UX
- Modern-looking frontend and API behavior
These surface indicators often signal “secure enough” to end users - but security researchers know authentication ≠ authorization.
Even if a system correctly identifies who you are, it must still prove that you are allowed to access what you’re asking for.
Step 1 - Reconnaissance and API Mapping
Using Burp Suite as a proxy, the researcher began mapping endpoints, capturing patterns, and analyzing API behaviors.
After logging in normally, most endpoints looked clean and scoped to the authenticated user. Until one critical request appeared:
The statement-fetching API
This endpoint generated monthly prepaid bill PDFs for users.
Everything seemed normal in the UI - but behind the scenes, the API relied entirely on client-supplied parameters, and the server did not validate ownership of the requested consumer number.
That single oversight is the textbook definition of an IDOR.
Step 2 - Confirming the IDOR (Safely & Non-Intrusively)
The researcher followed strict responsible validation practices:
- No harvesting of sensitive data
- No downloading real user statements
- Only observing whether unauthorized requests were accepted or rejected
- Using synthetic or redacted identifiers for sampling
- Monitoring server patterns without accessing actual PII
The API behavior revealed:
- Any authenticated user could request any consumer number
- The server returned complete statement data without ownership verification
- Identifier patterns were simple and predictable
- Enumeration was possible
This is more than an IDOR - it is an unrestricted nationwide PII exposure vector.
Why This IDOR Was Catastrophic
Three factors combined to elevate severity:
1. Rich PII inside statements
Each PDF contained personal details:
- Full name
- Phone number or email
- Billing address
- Billing cycle information
- Consumer number structure
- Transaction details
2. Highly enumerable parameter
consNo used predictable formatting, enabling large-scale enumeration.
3. Massive impact radius
By observing response behavior (without downloading data), the researcher estimated that approximately:
➝ 6.4 million accounts were potentially exposed.
When PII exposure, scalable enumeration, and sensitive internal data intersect, a simple IDOR becomes a critical systemic breach.
Step 3 - Reporting to the Organization (Silence & Friction)
The researcher prepared a professional and redacted report containing:
- Vulnerable endpoint (
/pdfEngine/v2/prepaidStatement) - API explanation
- Exact nature of the missing authorization check
- Potential impact to millions
- Suggested remediation steps
But the organization:
- Did not have a bug bounty program
- Did not have a security contact
- Did not have a disclosure policy
- Only had a generic “Contact Us” form
Multiple attempts, follow-ups, and responsible outreach attempts received:
❌ No acknowledgement
❌ No ticket
❌ No appreciation
❌ No confirmation
This is a common and dangerous gap in many organizations: security issues ignored due to non-existent disclosure processes.
Step 4 - Escalation to CERT-In
Since:
- the application was India-based, and
- it handled critical citizen billing data,
the researcher escalated to CERT-In, the national cybersecurity response authority.
CERT-In received a full, professionally written, redacted, and evidence-backed report containing:
-
Endpoint details (with sensitive parameters removed)
-
Explanation of missing authorization control
-
Estimated impact (~6.4M users)
-
Recommended remediations:
- Authorization middleware
- Non-enumerable identifiers
- Response scoping to authenticated user
- Better API design patterns
Within days, CERT-In acknowledged receipt and began coordination with the affected organization.
They confirmed:
- The vulnerability was real
- It had high-severity implications
- It required urgent remediation
Step 5 - Final Outcome
CERT-In successfully coordinated the fix.
The organization silently patched the endpoint:
- Ownership checks added
- Statement access restricted to the actual user
- Enumeration paths closed
- PII exposure prevented
Later, the researcher was honored with an official CERT-In Hall of Fame acknowledgement for protecting millions of users.
What started as a casual test became a nation-level data protection effort.
Defensive Perspective
Authorization failures - especially IDORs - continue to plague production APIs worldwide. The fix is simple conceptually but often overlooked during development.
What should developers do?
| Control | Description |
|---|---|
| Server-side authorization | Always validate that the requesting user owns the requested resource |
| Use opaque IDs | Avoid sequential or easily guessable identifiers |
| Scope responses | Only return data belonging to authenticated identity |
| Input validation | Validate consumer numbers, IDs, and ensure invariants |
| Logging & monitoring | Detect unusual sequential access or scraping patterns |
| Error shaping | Use identical error responses to avoid information leaks |
| Rate limiting | Prevent high-speed enumeration attempts |
Beginner Breakout - Authentication vs Authorization
- Authentication → Are you who you say you are?
- Authorization → Are you allowed to access this specific resource?
Most breaches happen when developers authenticate correctly, but incorrectly assume that authentication equals access permission.
Troubleshooting & Common Pitfalls
- Testing with only your own account hides IDORs
- Client-side checks (JS-based restrictions) mislead engineers
- Predictable identifiers are the backbone of most IDOR exploitation
- PDF/statement APIs are common blindspots since devs assume “user-specific” = “safe by design”
- No bug bounty or disclosure policy increases response delays drastically
- Login + OTP ≠ authorization security
Final Thoughts
This case study is a reminder that:
- Not all vulnerabilities are sophisticated
- Sometimes the biggest breaches come from the simplest missing check
- A single endpoint with predictable identifiers can expose millions
- Organizations must establish disclosure channels
- And researchers must act responsibly, even when ignored
A casual test turned into preventing a 6.4 million-person data leak - and earned a well-deserved CERT-In Hall of Fame mention.
Test deeply. Validate responsibly. Report ethically.
Happy hacking! 🛡️
