I'm Sagar Kirola, and in this writeup I'll share multiple API vulnerabilities I discovered while testing a SAAS workplace communication and collaboration platform it was the same target that i discuss in my first writeup if you did't read it yet give it a sort.
Due to NDA restrictions, I can't disclose the actual company name, so throughout this article I'll refer to the target as target.com.
I will keep the writeup to the point.
During testing, I discovered several API-level authorization issues that allowed low-privileged users and administrators to bypass Role-Based Access Control (RBAC) restrictions and perform sensitive actions they were never supposed to access.
The vulnerabilities included:
- Arbitrary User Suspension Through API Manipulation
- Permission ID Manipulation Leading to RBAC Bypass
- Unauthorized Sub-Admin Creation and Deletion
- Forced Logout of Arbitrary Users (IDOR)
Although the issues affected different features in a single application, they all shared a common root cause:
The backend APIs trusted user-controlled values and failed to properly enforce authorization checks server-side.
About the Application
target.com is a workplace communication and collaboration platform used by organizations to manage employees, communication, security settings, and administrative operations.
The application supported multiple administrative roles with different privilege levels.
Super Admin
The highest privileged role with full control over the organization.
Sub Admin
A higher-level administrative role with broader permissions than lower-level admins.
Operational Admin
A lower-privileged administrative role intended for limited operational functionality such as inviting users and handling basic management tasks.
Custom Admin Roles
The application also allowed organizations to create custom admin roles with granular permission controls.
The vulnerabilities discussed in this writeup affected multiple parts of the platform's authorization model.
Vulnerability 1— Arbitrary User Suspension Through API Manipulation
There is a feature where a Super Admin can create custom admin roles and assign them specific permissions to control what actions they can perform within the platform. For example, a custom admin can be given access to only "Group Management" while all other functions like member management, suspension, and account control remain restricted.
The UI enforces these restrictions correctly — when a custom admin tries to access a blocked function, the interface prevents it and shows an error.
However, the restriction only exists on the frontend. The backend API does not perform the same authorization checks. This means a custom admin can bypass the UI entirely by sending a direct API request using their own session cookies to endpoints they are not supposed to access.
In this case, a custom admin with only "Group Management" permission was able to hit the suspension endpoint directly:
POST https://target.com/api/<permission-id>/endpoint/endpoint/v1/users/<user-id>/suspendThe server processed the request successfully and suspended the target user — without ever checking whether the requesting admin actually had suspension privileges.
Impact: A low-privileged custom admin can suspend any user in the organization, including Super Admins and other higher-privileged accounts, simply by making a direct API call — completely bypassing the intended role-based restrictions.
Vulnerability 2 — Permission ID Manipulation Leading to RBAC Bypass
There is a feature in target.com where every admin role is assigned a unique permission ID that determines which parts of the platform they can access. These permission IDs are included directly in API request URLs to control what features the admin can interact with:
GET https://target.com/api/{Permission_ID}/admin/admin-auth/authsThe UI correctly restricts low-privileged admins from accessing features outside their assigned role. A custom admin with minimal permissions can only see and interact with what they are explicitly allowed to.
However, the backend API does not validate whether the permission ID in the request actually belongs to the authenticated user. This means a low-privileged admin can simply replace their own permission ID in the URL with one belonging to a higher-privileged feature and the server will process it without any authorization check.
For example, a low-privileged admin with permission ID 53463G5 can modify their request to use a higher-privileged permission ID 8L52590:
GET https://target.com/api/8L52590/admin/admin-auth/authsThe server grants full access to the restricted feature — without ever verifying whether the requesting admin is authorized to use that permission ID.
Impact: A low-privileged admin can access any restricted admin functionality across the entire platform. This includes modifying security settings, managing users, resetting passwords, creating or demoting admin roles, and accessing sensitive organizational data. Because the flaw exists at the authorization logic level, it is not limited to a single feature — an attacker can perform any action a full admin can, effectively taking complete control over the organization.
Vulnerability 3 — Unauthorized Sub-Admin Creation and Deletion
There is a feature in target.com where admins can assign or remove roles from members. The platform has a role hierarchy — Operator Admins are lower-level admins with limited powers, Sub-Admins are higher-level admins with more control, and the Supreme Admin is the organization owner. By design, only Sub-Admins and above are supposed to be able to create or manage other Sub-Admins. Operator Admins are strictly not allowed to do this.
The UI enforces this correctly — an Operator Admin cannot access Sub-Admin management through the interface.
However, the backend does not validate the role name included in the request URL. When an Operator Admin assigns their own role to a user, the request looks like this:
POST /api/<permission-id>/admin/endpoint/auths/opAdmin/users/<user-id>By simply changing opAdmin to subAdmin in the URL:
POST /api/<permission-id>/admin/endpoint/auths/subAdmin/users/<user-id>The server processes the request and promotes the user to Sub-Admin — without ever checking whether the Operator Admin is authorized to assign that role.
Then i thing to change the request method to DELETE and yeah its work too.
DELETE /api/<permission-id>/admin/endpoint/auths/subAdmin/users/<user-id>An Operator Admin can remove a legitimate Sub-Admin account entirely. Notably, the server may return a 400 Bad Request response — but the action is still carried out in the background regardless.
Impact: An Operator Admin can promote any user to Sub-Admin or delete existing Sub-Admins without authorization. This completely bypasses the role-based access control system, allowing a low-level admin to manipulate the organization's admin hierarchy, escalate privileges, and disrupt legitimate administrative control.
Vulnerability 3— Forced Logout of Arbitrary Users (IDOR)
There is a feature in target.com where users can terminate their own active session through the account settings. When a user logs out, the platform sends a request with the user's ID directly in the URL:
POST /api/user/<endpoint>/admin/access/disconnect/<user-id>The UI only allows users to log out of their own session. However, the backend performs no ownership validation — it never checks whether the user making the request actually owns the session they are trying to terminate. This means any member-level user can replace the user ID in the URL with someone else's ID and forcefully log them out.
What makes this significantly worse is that user IDs follow a predictable numeric pattern. Every user can see their own ID, which typically starts with a consistent prefix such as 12 or 34. From this, an attacker can easily infer that other users in the same organization share the same prefix — for example 34xxxxxxx. This dramatically reduces the brute-force space, making it trivial to enumerate valid user IDs without any special access or privileges.
Even without knowing exact IDs, an attacker can brute-force the remaining digits sequentially, monitor server responses to identify active accounts, and pinpoint which IDs belong to privileged users. With no rate limiting or blocking in place, an attacker can send 50–100 requests per second — trying thousands of IDs within minutes.
Impact: A regular member-level user can forcefully log out any user in the organization — including Admins and Supreme Admins — simply by modifying the user ID in the request. Because the IDs are predictable and there is no rate limiting, this can easily be automated to target hundreds of accounts at scale, causing repeated session disruptions for key personnel and bringing organizational operations to a halt.
THANK YOU READING……..