Sometimes the most interesting vulnerabilities are not complex exploits or advanced attacks — they are small logic mistakes that quietly expose sensitive data.

Recently, while testing a learning platform (let's call it example.com), I discovered a case where a regular learner could see personal information of other users inside the organization.

This issue turned out to be a classic Broken Access Control vulnerability.

Let me walk you through how this happened.

🧭 The Starting Point

The platform allowed organizations to create learning cards and assign them to employees.

There were different roles such as:

• Owner
• Admin
• Learner

Normally, learners should only see their own progress and content assigned to them.

They should not have visibility into other users' personal data.

But during testing, I noticed something interesting.

🔍 Creating Test Accounts

To understand the system behavior, I created two accounts:

• Account A — Organization Owner
• Account B — Learner

After setting up the learner account from the admin dashboard, I logged into the learner application using the learner credentials.

Everything looked normal at first.

But the real story started when I began inspecting the network traffic.

🕵️ Intercepting the Requests

Using Burp Suite, I intercepted the requests that were sent when the learner logged into the platform.

Two API endpoints appeared during authentication:

POST /api/v6/auth/local
GET /api/v6/refresh/data

The second endpoint looked particularly interesting.

So I inspected the response carefully.

📦 Unexpected Data in the API Response

Inside the response of:

GET /api/v6/refresh/data

I noticed a JSON object called:

leaderboards

At first glance, it looked harmless.

But when I expanded it, I saw something unexpected.

The response contained information about other users in the organization.

Example response:

"leaderboards": {
  "all": [
    {
      "id": 19025,
      "firstname": "testing",
      "lastname": "users",
      "avatar": null,
      "email": "user1@examplemail.com",
      "position": 1,
      "points": 2
    },
    {
      "id": 19022,
      "firstname": "admin",
      "lastname": "user",
      "avatar": null,
      "email": "owner@examplemail.com",
      "position": 2,
      "points": 0
    }
  ]
}

This meant that a simple learner account could see data belonging to other users.

⚠️ What Data Was Exposed?

The API response revealed several pieces of sensitive information:

• Full names
• Email addresses
• Profile images
• Internal user IDs
• Leaderboard ranking

Even more concerning, the response included information about high-privileged users such as administrators and organization owners.

This data was accessible without any special permissions.

🧨 Why This Is a Security Problem

At first glance, this might look like a minor issue.

But in a real organization environment, this can lead to serious problems.

Imagine a company with thousands of employees using the platform.

A single learner could potentially:

• Enumerate all employee email addresses
• Identify administrators or owners
• Launch targeted phishing campaigns
• Perform social engineering attacks
• Harvest company user data

This is exactly the type of issue described in OWASP Top 10 — Broken Access Control.

The platform returned more data than the user was authorized to see.

🧠 What Should Have Happened

For learner users, the API should only return minimal information.

For example:

• The learner's own profile
• Their score or ranking (if needed)

It should not return personal information of other users.

A secure leaderboard implementation could show something like:

Rank 1 – User #1
Rank 2 – User #2
Rank 3 – You

Without revealing emails or internal identifiers.

🛡️ How This Could Be Fixed

The issue can be resolved by applying a few simple security practices.

1. Implement Role-Based Access Control

API responses must be filtered based on the user's role.

Learners should not receive organization-wide data.

2. Apply Data Minimization

Only return fields that are strictly necessary.

Sensitive fields like:

• email
• internal user id
• avatar
• full name

should not be included.

3. Secure the Leaderboard API

Leaderboard responses should use anonymized data.

User identities should not be exposed unless explicitly required.

📊 Vulnerability Severity

Based on standard risk scoring, this issue falls under:

High Severity

Reason:

• Exploitable by a low-privileged user
• No user interaction required
• Exposure of sensitive personal data

🏆 Bounty

After responsibly reporting the vulnerability, the security team reviewed the report and confirmed the issue.

They acknowledged that the API was exposing more data than intended and validated the finding.

Later, I received the following message from the team:

The report has been reviewed and confirmed as valid. Please send a PayPal invoice or an invoice containing your PayPal address to receive your $50 reward.

Responsible disclosure like this helps improve platform security and protects user data.

🎯 Final Thoughts

One of the key lessons in bug bounty hunting is this:

Not every vulnerability comes from complex exploitation. Sometimes it comes from returning too much data.

APIs often expose hidden information that the frontend does not display.

This is why inspecting API responses carefully is extremely important during security testing.

A small oversight in access control can quietly expose sensitive information to users who should never see it.

And that is exactly what happened here.

If you enjoyed this write-up, feel free to connect with me and follow my bug bounty journey. 🚀

Happy Hacking! 🚀