I Wasn’t an Admin — Until I Played with One API

Introduction

Role-Based Access Control (RBAC) is one of the fundamental security mechanisms used in modern applications. It ensures that users can only access features and data that align with their assigned privileges.

When implemented correctly, RBAC prevents unauthorized access to sensitive functionality. However, when authorization checks rely on client-controlled input, the security model can quickly collapse.

During a security assessment, I encountered a privilege escalation vulnerability that allowed a low-privileged user to elevate their role simply by modifying an API request.

No exploits. No bypasses. Just changing a single parameter.

What is Privilege Escalation?

Privilege Escalation occurs when a user gains access to permissions or functionality beyond what they were originally granted.

This often happens when applications fail to enforce proper authorization checks on the server side.

A common mistake is trusting values supplied by the client, such as role identifiers or access levels.

Example (Sanitized):

{
  "userId": "12345",
  "roleCode": "EAU"
}

{
  "userId": "12345",
  "roleCode": "EAU"
}

By modifying the role value:

{
  "userId": "12345",
  "roleCode": "ADM"
}

{
  "userId": "12345",
  "roleCode": "ADM"
}

the server accepted the request and updated the user's privileges without validating whether the authenticated user was authorized to assign administrative roles.

At that point, the application effectively granted elevated access to itself.

Root Cause

The vulnerability originated from multiple design flaws:

Missing server-side authorization checks
Trusting client-supplied role identifiers
Inadequate validation of role assignments
Improper enforcement of Role-Based Access Control (RBAC)

The core issue was simple:

The application assumed that because a request came from an authenticated user, the user was authorized to perform role modifications.

Authentication and authorization are not the same thing.

Attack Scenario

Consider a practical scenario.

An attacker logs into the application using a standard low-privileged account.

While updating profile information, the attacker intercepts the API request using an intercepting proxy.

Inside the request payload, they discover a parameter controlling the user's role.

The original request contains:

"roleCode": "EAU"

"roleCode": "EAU"

The attacker changes it to:

"roleCode": "ADM"

"roleCode": "ADM"

"roleCode": "SU"

"roleCode": "SU"

The modified request is forwarded to the server.

The server processes the request successfully and updates the user's role without performing authorization checks.

After logging back into the application, the attacker gains access to administrative functionality that should have been restricted.

No sophisticated exploitation was required.

The application trusted user input more than it should have.

Exploitation Methodology

A structured approach to identifying this vulnerability includes:

1. Identify Role Management Functionality

Locate endpoints responsible for user updates, profile management, or role assignments.

2. Intercept Requests

Use an intercepting proxy to capture requests containing role-related parameters.

3. Modify Role Values

Change role identifiers to higher-privileged values and observe server behavior.

4. Validate Access

Re-authenticate if necessary and verify whether elevated privileges have been granted.

The severity of this vulnerability depends on the permissions associated with the elevated role.

Impact

Privilege escalation vulnerabilities can have severe consequences:

Unauthorized administrative access
Violation of RBAC controls
Exposure of sensitive data
Misuse of privileged functionality
Potential lateral movement within the application
Increased risk of further compromise

In many cases, privilege escalation becomes the stepping stone for more critical attacks.

Mitigation Strategies

Preventing this vulnerability requires strong server-side controls.

1. Enforce Server-Side Authorization

Every role modification request must be validated against the authenticated user's permissions.

2. Prevent Self-Role Modification

Users should never be allowed to modify their own roles through client-controlled parameters.

3. Implement Least Privilege

Assign only the minimum permissions required for each role.

4. Restrict Role Management

Role assignment functionality should be accessible only to authorized administrators.

5. Validate Sensitive Parameters

Never trust role identifiers supplied by the client. The server should determine what actions a user is permitted to perform.

Conclusion

Privilege escalation vulnerabilities are often deceptively simple.

A single unchecked parameter can transform a regular user into an administrator, bypassing the very controls designed to protect the application.

Security is not just about authentication. It is about ensuring that every action is authorized.

Because when applications trust the client too much, attackers do not need to break the rules.

They simply follow them.

Contents