Before starting this write-up, I would like to clarify that for responsible disclosure reasons, I will refer to the target as example.com

Understanding the Application

The target was a SaaS collaboration platform used by organizations to manage teams, projects, and internal communication.

The system followed a hierarchical structure. At the top were executive teams such as CEOs and board members, followed by management teams, and then operational teams like sales or support. Access control rules were clearly defined: higher-level teams could access lower-level team data, but lower-level teams were not allowed to view any information belonging to higher-level teams.

From a design perspective, the role-based access model appeared to be properly implemented.

Before starting hunting my mind says IDOR,BAC,PRIVESC ...

None
Excitement

Initial Testing Approach

I began testing by understanding how team-level permissions were enforced across different features. Since the platform allowed navigation across multiple teams within an organization, I started with basic access control testing.

As a member of a lower-privileged team, I could access teams below my hierarchy level, but I could not access teams above mine. This confirmed that the basic permission logic was working as expected.

Naturally, the next step was to attempt an IDOR-style test by modifying team identifiers in requests. Since I could legitimately access lower-level teams, I tried changing team IDs to those belonging to higher-privileged teams.

However, these attempts failed. The application correctly validated permissions and blocked unauthorized access when trying to directly retrieve higher-level team data.

None
Failed

At this stage, it seemed that access control mechanisms were properly enforced.

Exploring Data Retrieval Endpoints

I continued analyzing how the application fetched team data. While observing network traffic, I noticed that certain operations relied on GET requests containing team identifiers.

I tested these endpoints by manipulating the team ID parameter, but again, the server consistently enforced authorization checks. Direct data retrieval paths were secure.

Since direct access attempts were unsuccessful, I shifted focus to less obvious functionality that might interact with sensitive data.

The Overlooked Feature

While exploring the dashboard further, I came across an Export Data option. This feature allowed teams to download their internal data in a file format.

Export features often handle large amounts of sensitive information, so I decided to test whether proper authorization checks were applied here.

The Discovery

When initiating a data export, I intercepted the request and analyzed its parameters. The request included a team identifier, similar to other endpoints.

I modified this identifier and replaced it with the ID of a higher-privileged team. The expectation was that the server would reject the request.

None
Exported data

Instead, the server processed it successfully and returned a downloadable file.

None
Let's Go

This confirmed that the export functionality did not validate whether the requesting user was authorized to access the specified team's data.

With all these I documented eveything and reported to the organization .

None

Since it's in triage mode am diclosing this without mention the organization name.

Impact

The exported files contained sensitive internal information, including team discussions, project details, and organizational data. This meant that a low-privileged employee could extract private data belonging to executive or restricted teams.

In a real-world scenario, such a vulnerability could lead to data leaks, insider threats, exposure of confidential communications, and significant reputational damage to the organization.

Root Cause

The issue existed because the export feature relied solely on a client-supplied team identifier without performing proper server-side authorization checks. While other parts of the application correctly enforced role-based access control, this specific functionality failed to do so.

This created a classic Broken Access Control vulnerability with characteristics similar to an IDOR flaw.

Conclusion

This finding highlights how a single overlooked feature can undermine an otherwise well-implemented access control system. Even when direct access paths are secure, indirect functionality such as export mechanisms can introduce critical vulnerabilities if proper authorization checks are not enforced consistently.

The key lesson is that security must be applied uniformly across all features, especially those that handle sensitive data.

This issue was responsibly disclosed, and all sensitive details have been anonymized.

Tip Even a heavily tested site is not secure.

Happy Hacking! — Dedrknex

Let's connect on X