# Exploiting Role -Based Access Control Misconfiguration -PortSwigger Lab Walkthrough

### Introduction

In this lab, we exploit a flawed access control mechanism where user roles are controlled through a client-side modifiable field. Our goal is to an admin and accessing a restricted `/admin` page to delete the user **carlos**.

### Understanding the Lab

**Step 1: Log in to the Application**

The lab provides default credentials to log in:

1. **Username**: wiener
    
2. **Password**: peter
    

After logging in, browse around the site and take note of features like the account settings page.

**Step 2: Intercept and Modify the Role**

Open **Burp Suite** and intercept the request while updating your profile or browsing to your account section. Look for any parameter related to user roles. You’ll find something like this in a request:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744611921580/8e1e0684-e288-4d7e-bce0-c0ab12a9e940.png align="center")

This indicates that the current user has a `roleid` of 1, which means normal user.

Modify it to:

<mark>‘roleid’=2</mark>

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744611962786/6aa4a7af-925a-4369-846a-205f7430cecc.png align="center")

and forward the request. This tricks the server into thinking the user is now an admin.

**Step 3: Access the Admin Panel**

Now go to lab

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744611985413/7b840654-0ef7-430a-9cfe-eb5753930f88.png align="center")

Since your role has been changed to admin, you should gain access to the panel.

**Step 4: Delete User ‘Carlos’**

Inside the admin panel, look for a user management section. There, you’ll find the option to delete the user **carlos**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744612010976/c9b2873e-4722-49c9-923c-eec3d5e520b0.png align="center")

Once you click delete, the lab will show a success message confirming that it’s solved

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744612058490/cf181433-1c37-41f2-9b4d-f61de607176e.png align="center")

### Root cause

The vulnerability here is **Broken Access Control**. The application trusts user-supplied data (in this case, the roleid) and fails to verify the role on the server side. This allows an attacker to elevate privileges just by modifying a request parameter.

### Mitigations

1. Never rely on client-side values for authorization decisions.
    
2. Store and enforce roles on the server side based on secure session data.
    
3. Implement access control checks on every sensitive route(like `/admin`).
    

### Conclusion

This lab is a classic example of what happens when access control is handled insecurely. It teaches us how small oversights can lead to full admin access and even user deletion . Always enforce roles and permissions on the backend, not the client!