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:

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

Modify it to:

‘roleid’=2

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

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.

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

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!