A Short Pentest Story The target was a multi-tenant SaaS platform used by enterprise customers to manage customer communications through SMS, WhatsApp, and email. It also supported webhook integrations with external systems, allowing authentication credentials to be stored securely within the platform. Like any multi-tenant application, it relied on two fundamental security assumptions: role-based access control and strict tenant isolation.

Unfortunately, neither assumption held.

The assessment began with what looked like a simple authorization issue. The application exposed a well-designed RBAC model through the UI administrative functions were hidden, privileged features were unavailable to low-privileged users, and everything appeared properly restricted. The illusion disappeared after replaying the first API request.

Using a read-only account, we successfully modified the last name of an administrator. No privilege escalation, no token manipulation, just a request that the backend should have rejected but happily accepted. It quickly became clear that authorization was largely enforced by the frontend, while the backend trusted requests without performing proper permission checks. Luckily the server responded with: The successful modification was confirmed by issuing a subsequent request: The server responded with the newly updated data: Further testing showed the issue wasn't limited to user management. Administrative functionality, including webhook configuration, was also accessible through the API. A low-privileged user could create or modify webhook credentials despite having no administrative permissions. In environments where webhook credentials authenticate communication with external systems, this represents far more than a simple configuration issue. Response disclosed credentials to the callback server: But… There were a serviceAccounts keyword and a tenant_uuid in the path of previous request. A simple modification of the request URL allowed for the enumeration of all existing tenants: Server responded with close to 3000 records containing information about tenants: With a list of valid tenant UUIDs available, the next logical step was to test whether changing the tenant context would allow access to stored secret-related information: This attempt was successful, confirming that tenant isolation was not properly enforced: No write operations were performed against foreign tenants. Once cross-tenant access had been demonstrated, further exploitation would only have increased operational risk without providing additional evidence. Sometimes the best proof-of-concept is knowing exactly where to stop.

What started as a simple Broken Access Control issue turned into a platform-wide trust boundary failure affecting approximately 3,000 tenants. The attack did not require sophisticated techniques, clever bypasses, or advanced exploitation, the backend simply accepted requests it should never have trusted. Impact Summary • A low-privileged user could bypass authorization controls and access functionality intended for administrators.

• Administrative data, user roles, and configuration settings could be modified without proper permissions.

• Unauthorized users could manage webhook integrations and credentials used for external communication workflows.

• Messaging capabilities (SMS, WhatsApp, and email) could potentially be abused due to missing backend authorization checks.

• Tenant enumeration combined with missing isolation controls exposed the possibility of affecting other customer environments.

• The vulnerability chain represented a potential platform-wide security compromise affecting approximately 3,000 tenants.
The lesson learned The frontend can hide a button, but it cannot enforce security. A hidden menu item may improve the user experience, but it will never stop someone from crafting a request manually. Attackers do not click what they see, they analyze what the application sends, modify what they want, and ask the backend questions it was never supposed to answer. Security decisions must always be enforced server-side, because the frontend is only a guide for users, not a security boundary.