How I Found a Broken Access Control Vulnerability During a Penetration Test

If there's one vulnerability I keep running into during penetration testing, it's Broken Access Control. It doesn't always involve complicated payloads or advanced techniques. Sometimes, it's simply about understanding how an application works and asking yourself, "What if I try to access something I'm not supposed to?"

During one of my assessments, I was testing a financial application with two different roles: Administrator and Normal User.

The administrator had access to a user management module where they could create users, assign permissions, and view information about every user in the system. A normal user, on the other hand, could only access their own account and the features assigned to them.

From the UI, everything looked secure. When I logged in as a normal user, there was no sign of any administrative functionality. No admin menu, no user management page — nothing.

But experience has taught me that what the UI hides doesn't always reflect what the backend protects.

Something Caught My Attention

I began exploring the application using a normal user account and intercepted one of the requests in Burp Suite.

While reviewing the request, I noticed a parameter named path. It appeared to determine which functionality the server should load.

Instead of making random changes, I wanted to understand how the application handled different user roles.

So, I logged in with an administrator account and intercepted the request for the user management page.

When I compared both requests, I noticed they were almost identical. The only significant difference was the value of the path parameter.

That immediately made me wonder:

Was the server actually checking whether the logged-in user was allowed to access that path, or was it simply trusting whatever value the client sent?

Testing My Assumption

To find out, I copied the administrator's path value and replaced the normal user's path while keeping the normal user's session unchanged.

I sent the modified request…

And to my surprise, it worked.

Instead of rejecting the request with a 403 Forbidden, the application returned the administrator's user management page.

Using nothing more than a normal user account, I was able to access information that should have been available only to administrators.

What Went Wrong?

The application correctly authenticated me as a normal user, but it failed to verify whether I was authorized to access the requested functionality.

Instead of enforcing access control on the server, it relied on a client-controlled parameter to determine which resource to load.

In other words, the backend trusted the request more than it trusted the user's role.

This is a textbook example of Broken Access Control, specifically Vertical Privilege Escalation, where a low-privileged user gains access to administrator-only functionality.

What I Learned

This finding reinforced something I always keep in mind during assessments:

Never assume a hidden feature is a protected feature.

Just because an option isn't visible in the interface doesn't mean it's inaccessible. If the backend doesn't validate authorization on every request, a simple request modification can sometimes expose functionality that was never meant to be reachable.

This vulnerability wasn't discovered by running an automated scanner or using a complex exploit. It was found by understanding the application's behaviour, comparing requests between different user roles, and asking one simple question:

"What happens if I request the admin functionality using a normal user's session?"

Sometimes, that's all it takes to uncover a critical vulnerability.

Thankyou!!!