How I Discovered a Critical IDOR Vulnerability That Exposed 10000+ Users’ Data -Canadian E-commerce…

How I Discovered a Critical IDOR Vulnerability That Exposed 10000+ Users' Data -Canadian E-commerce Platform. A Real-World Bug Bounty Story — Responsible Disclosure, CVSS 9.1

Introduction

Security vulnerabilities are everywhere even in production applications used by hundreds of real users. During one of my routine security assessments, I stumbled upon a critical Insecure Direct Object Reference (IDOR) vulnerability that allowed any authenticated user to access the entire user database of a live platform.

This is the story of how I found it, what it exposed, and what every developer should learn from it.

Severity: Critical — CVSS Score 9.1 Type: IDOR — Broken Object Level Authorization (BOLA) Status: Responsibly Disclosed and Acknowledged ✅

1. What is IDOR and Why Does It Matter? Insecure Direct Object Reference (IDOR) is a type of access control vulnerability that occurs when an application uses user controllable input to access objects directly without verifying whether the user is actually authorized to access them.

IDOR consistently appears in the OWASP Top 10 under Broken Access Control the #1 most critical web application security risk.

In simple terms: A regular user should never be able to access admin level data just by modifying a parameter.

But that is exactly what I found.

2. How I Discovered It

I was testing a web application as an authenticated standard user. During my reconnaissance, I began exploring the API endpoints being called by the frontend a normal practice in web security testing.

Using Burp Suite, I intercepted the API requests and noticed something interesting:

GET /api/user/ALL?role=admin Authorization: Bearer [my regular user token]

My eyes immediately locked onto one thing — ?role=admin

The application was passing the user's role as a client-side query parameter. This immediately raised a red flag. Why would a secure application trust the client to declare its own role?

Steps I Followed

1. Registered a standard user account
2. Authenticated and obtained a valid JWT Bearer token
3. Intercepted the API call using Burp Suite
4. Modified the request to append ?role=admin
5. Forwarded the request and observed the response

What came back was shocking.

3. Technical Details

Affected Endpoint

GET /api/user/ALL?role=admin Authorization: Bearer [valid standard user token]

The Root Cause

The application was making a fatal authorization mistake:

Instead of reading the user's role from the server-side verified JWT payload, the backend was trusting the client supplied ?role=admin query parameter to make authorization decisions.

This means:

• The JWT token was only used for authentication (proving who you are)
• But authorization (what you can do) was controlled by a parameter anyone could modify

What the Response Returned

The API returned the complete user database — over 10000+ registered users — including:

4. Impact of the Vulnerability

This was not just a theoretical risk. The impact was immediate and severe:

Privacy Impact

• Mass disclosure of Personally Identifiable Information (PII)
• Every registered user's personal data was exposed to any authenticated attacker Compliance Impact
• Potential GDPR violations — unauthorized access to EU/international user data
• Potential PIPEDA violations — Canada's Personal Information Protection law
• Could result in significant regulatory fines and legal liability

Security Impact

• Phishing attacks — attackers now have names, emails, and phone numbers
• SIM swap attacks — mobile numbers exposed
• Account takeover — 2FA status and login attempt data revealed
• Privilege escalation — further IDOR exploitation possible throughout the app

Business Impact

• Complete loss of user trust if exploited
• Potential data breach notification requirements
• Reputational damage to the platform

A single HTTP request with a modified parameter was enough to download the personal data of every user on the platform. That is how serious this was.

5. How It Was Fixed

After responsible disclosure, the development team acknowledged the vulnerability and implemented the following fixes:

Remediation Steps Applied

1. Removed client-side role parameters All authorization logic based on query parameters was completely removed from privileged endpoints.

2. Server-side JWT validation enforced User roles are now derived exclusively from the verified JWT payload on the server side — never from client-supplied input.

3. Authorization middleware implemented A dedicated authorization middleware was added to all privileged API routes:

4. Full API security audit conducted The team reviewed all API endpoints for similar authorization bypass vulnerabilities.

5. Monitoring and rate limiting added Suspicious request patterns are now monitored and rate limited at the API gateway level.

6. Lessons Learned

This vulnerability taught me — and hopefully teaches you — some very important lessons:

For Developers 👨‍💻

Never trust client-supplied input for authorization decisions.

• Always validate roles and permissions server-side
• Your JWT token should be the single source of truth for user identity and role
• Apply the principle of least privilege — users should only access what they need
• Add authorization middleware to every sensitive endpoint
• Conduct regular API security reviews

For Security Researchers 🔍

• Always check API parameters — especially ones named role, admin, type, access
• IDOR vulnerabilities are often found by simply modifying IDs and parameters
• Always practice responsible disclosure — give companies a chance to fix before going public
• Document everything with screenshots and request/response pairs
• A CVSS score helps companies understand severity quickly

For Everyone 🌍

• Bug bounty programs exist for a reason — ethical hackers protect real users
• Responsible disclosure is a win-win — companies fix issues, researchers build credibility
• Security is not just a developer problem — it is a team responsibility

Key Takeaways

✅ IDOR is still one of the most common critical vulnerabilities
✅ Client-side parameters should NEVER control authorization
✅ JWT tokens must be validated server-side for every request
✅ Responsible disclosure protects real users
✅ Always audit your APIs for broken access control

✅ IDOR is still one of the most common critical vulnerabilities
✅ Client-side parameters should NEVER control authorization
✅ JWT tokens must be validated server-side for every request
✅ Responsible disclosure protects real users
✅ Always audit your APIs for broken access control

Final Thoughts

Finding this vulnerability was a reminder that even simple oversights can have massive consequences. A single misplaced trust in a client supplied parameter exposed the personal data of hundreds of real people.

As security researchers, our job is not to exploit. It is to protect. Responsible disclosure is what separates ethical hacking from malicious hacking.

I reported this vulnerability privately, gave the team time to fix it, and only wrote about it after confirmation that it was resolved. That is how it should always be done.

If you are a developer, audit your APIs today. If you are a security researcher, keep hunting — the web needs you.

Tags: #BugBounty #WebSecurity #IDOR #CyberSecurity #EthicalHacking #ResponsibleDisclosure #OWASP #APISecurity #JWT #PenTesting

👏 If this article helped you, please clap and follow for more real-world security research stories.