Introduction

My name is Montaser Mohsen, and I am a security researcher focused on discovering vulnerabilities related to Broken Access Control, Authentication, and API Security.

Over the past years, I have spent a significant amount of time analyzing modern web applications and APIs, especially SaaS platforms that rely heavily on role-based access control systems. One of the most common — and dangerous — classes of vulnerabilities I encounter is improper authorization validation on backend APIs.

In this article, I will walk through a real-world Broken Access Control vulnerability I discovered in a collaborative workspace management platform during a private bug bounty engagement.

To respect the disclosure policy, all sensitive information, identifiers, and company-specific details have been removed.

About the Program

The target application was a SaaS platform that allowed organizations to manage collaborative workspaces, users, projects, and permissions.

The platform implemented multiple user roles, including:

  • Administrators
  • Regular members
  • Workspace-level permissions

Administrators had the ability to:

  • Invite users
  • Modify user roles
  • Remove users from workspaces

At first glance, the application appeared to implement proper permission boundaries. However, deeper testing revealed a critical flaw in how authorization checks were enforced on backend APIs.

The Vulnerability

The issue existed in several workspace management endpoints.

After an administrator was removed from a workspace, the backend continued authorizing privileged actions through direct API requests.

This meant that a user who should no longer have any access to the workspace could still:

  • Enumerate workspace users
  • Add new users
  • Promote users to ADMIN
  • Remove legitimate users

Essentially, the removed user could still fully manage the workspace.

Root Cause

The core issue was improper server-side authorization validation.

The backend failed to correctly verify:

  • Whether the user was still an active member of the workspace
  • Whether the user still possessed the required administrative privileges

Instead of enforcing authorization dynamically on each request, the system appeared to rely on stale authorization state.

Affected API Endpoints

The vulnerable functionality affected multiple workspace-management APIs similar to:

GET /rest/workspaces/{workspace_id}/users
POST /rest/workspaces/{workspace_id}/users
PUT /rest/workspaces/{workspace_id}/users/{user_id}
DELETE /rest/workspaces/{workspace_id}/users/{user_id}

These endpoints allowed direct management of workspace members.

Attack Scenario

The attack scenario was surprisingly simple.

Step 1 — Become an Administrator

The attacker legitimately holds administrative access to a workspace.

This is an important detail: The vulnerability did not require account compromise or credential theft.

Step 2 — Removal from Workspace

Another administrator removes the attacker from the workspace.

At this point, the attacker should completely lose access.

Step 3 — Replay API Requests

Even after removal, the attacker could continue sending direct API requests to the vulnerable endpoints.

For example:

GET /rest/workspaces/{workspace_id}/users HTTP/2
Host: target-application.com
Cookie: SESSION=valid_session

The server still returned the list of workspace users.

User Enumeration

The vulnerable API exposed sensitive workspace information including:

  • User identifiers
  • Roles
  • Membership status

Example response behavior:

[
  {
    "role": "ADMIN",
    "status": "ACTIVE"
  }
]

This allowed attackers to fully map workspace membership.

Privilege Escalation

The attacker could also add new users with administrative privileges.

Example request:

POST /rest/workspaces/{workspace_id}/users HTTP/2
Content-Type: application/json
{
  "email": "attacker@example.com",
  "role": "ADMIN"
}

Result: A brand-new administrator account was added successfully.

At this point, the attacker effectively regained permanent control.

Modifying Existing Roles

The vulnerability also allowed role modification of existing users.

Example:

PUT /rest/workspaces/{workspace_id}/users/{user_id} HTTP/2
Content-Type: application/json
{
  "role": "ADMIN"
}

This enabled arbitrary privilege escalation.

Deleting Users

Even legitimate administrators could be removed from the workspace.

Example:

DELETE /rest/workspaces/{workspace_id}/users/{user_id} HTTP/2

This introduced a direct integrity and availability impact.

Security Impact

The impact of this issue was severe.

A removed user could:

  • Regain administrative access
  • Establish persistent control
  • Remove legitimate administrators
  • Enumerate sensitive workspace data
  • Completely compromise workspace integrity

From a real-world perspective, this represented:

  • Broken Access Control
  • Privilege Escalation
  • Workspace Takeover

Interesting Part of the Triage

During triage, the issue became particularly interesting.

My testing indicated that the vulnerability persisted even after:

  • Logging out
  • Session expiration
  • Logging back in with a fresh session

Unfortunately, despite the demonstrated impact, the vulnerability was ultimately classified as a low-severity P4 issue.

The classification was based on:

  • The attacker previously being an administrator
  • The temporary authorization window caused by caching

While I respectfully disagreed with the final severity assessment, the case was still an interesting example of how authorization inconsistencies and stale permission states can lead to full administrative compromise.

Key Takeaways

This case highlights several important lessons for developers and security teams:

1. Always Enforce Authorization Server-Side

Never rely on cached or client-side permission state alone.

Every sensitive request must validate:

  • Current membership
  • Current role
  • Current authorization scope

2. Invalidate Permissions Immediately

Permission changes should propagate instantly across:

  • Sessions
  • Caches
  • Authorization layers

Delayed invalidation creates dangerous attack windows.

3. Broken Access Control Remains Extremely Common

Even mature SaaS platforms frequently struggle with:

  • Role synchronization
  • Session invalidation
  • Authorization consistency

Modern applications often become vulnerable due to distributed caching and microservice architectures.

Conclusion

Broken Access Control vulnerabilities continue to be one of the most impactful classes of security issues in modern applications.

Even short-lived authorization inconsistencies can result in:

  • Privilege escalation
  • Persistent compromise
  • Full administrative takeover

This research serves as another reminder that authorization logic must always be treated as a security-critical component.

Thanks for reading 🙏 I'll keep sharing more from my bug bounty journey.

Feel free to connect or share your thoughts

Facebook: https://facebook.com/montasermohsen98 Twitter (X): https://x.com/Montaser_M98 LinkedIn: https://linkedin.com/in/montasermohsen98