Vertical Privilege Escalation: Exploiting Broken Function Level Authorization in Hierarchical APIs

At XECbuild, we frequently audit complex Software-as-a-Service (SaaS) and financial technology platforms. A common architectural challenge in these environments is managing multi-tier, hierarchical Role-Based Access Control (RBAC). When platforms allow "Owners" to provision "Teammate" or sub-accounts, the authorization logic must flawlessly handle both horizontal (tenant-to-tenant) and vertical (sub-user to admin) boundaries.

During a recent independent security assessment of a major fintech platform, our methodology identified a critical Vertical Privilege Escalation vulnerability stemming from Broken Function Level Authorization (BFLA). This case study illustrates how missing bottom-up access constraints can expose highly sensitive internal operational tokens.

🔍 The Architectural Target: Hierarchical RBAC

The target application utilized a standard organizational hierarchy: high-privileged "Owner" accounts possessed full administrative control, while "Teammate" accounts operated with restricted, lower-privileged access within the same organizational tenant.

Our analysis focused on the core API endpoints responsible for retrieving user profile data. An initial test confirmed that the platform's horizontal authorization was intact—an authenticated user could not query the profile endpoint of a completely unrelated user ID (resulting in a correct 403 Insufficient Permissions response).

However, security testing must go beyond horizontal isolation. The critical question became: *How does the API handle a bottom-up query within the same tenant?*

⚙️ The Vulnerability: Bottom-Up BFLA

To test the vertical access controls, an authenticated request was intercepted using a lower-privileged Teammate session token. Instead of querying their own profile, the request was manipulated to target the specific backend ID of their higher-privileged Owner account.

Because both accounts shared the same underlying organizational merchantId, the backend authorization middleware falsely validated the request. It failed to enforce the strict hierarchical constraint that a sub-user should not possess direct read-access to the parent administrator's backend profile.

The API responded with an HTTP 200 OK, exposing the Owner's raw, unfiltered backend data object.

⚠️ The Business Risk: Leaking Operational Secrets

The severity of this BFLA vulnerability was compounded by the platform's failure to sanitize backend data before returning it to the client. The exposed JSON payload did not just contain standard Personally Identifiable Information (PII) like emails and phone numbers.

Critically, the response leaked the Owner's internal accessToken claim and sensitive system status configurations.

This represents a massive defense-in-depth failure. Server-side session tokens and internal operational claims must never be exposed—especially to a lower-privileged account. If this leaked token was utilized by internal microservices or downstream API integrations, the lower-privileged Teammate could potentially hijack the Owner's administrative context, leading to full organizational account takeover.

🏆 Remediation and Core Philosophy

This finding was responsibly disclosed to the fintech organization's security team. While they acknowledged the validity and high severity of the logic flaw, they informed us it was an issue they had recently identified internally. Independently uncovering an internally tracked, complex BFLA flaw is a strong validation of manual, precision-based API auditing.

The Key Takeaway for Enterprise Engineering Teams:

1. Enforce Directional Authorization: Authorization is not just about horizontal tenant isolation. APIs must enforce strict vertical constraints, explicitly denying read/write access when a user attempts to query an entity higher in the privilege hierarchy.
2. Data Minimization: APIs must never act as raw database dumps. Strip internal operational claims (such as access tokens, internal role flags, and system restriction codes) from all API responses unless explicitly required and requested by the authenticated owner of those claims.

At XECbuild, we specialize in dismantling complex authorization logic to ensure your hierarchical access controls are cryptographically enforced, not just cosmetically applied.