Broken Access Control remains the highest risk in the OWASP Top 10 not because it is hard to scan for, but because it's hard to reason about. Unlike Injection flaws or misconfigurations, Access Control failures usually come out of incorrect assumptions about how users will interact with an application.

In this case study, I document a manual analysis of three Broken Access Control scenarios, identified through hands-on testing using Burp Suite Proxy and Repeater. The focus was to be not on automation, but on understanding application logic, trust boundaries, and server-side authorization decisions.

The methodology applied throughout this assessment was consistent:

Reconnaissance → Request Analysis → Manual Exploitation → Impact Evaluation → Remediation.

Executive Summary

During manual testing of a web application, I identified three distinct Broken Access Control vulnerabilities affecting:

  • Object-level authorization (IDOR)
  • Method-based access enforcement
  • Multi-step workflow validation

Each vulnerability resulted from insufficient server-side authorization checks or misplaced trust in client-controlled input. All issues were validated manually using Burp Suite, demonstrating how logic flaws can persist even when perimeter defenses appear functional.

Scenario 1: Insecure Direct Object Reference (IDOR)

Vulnerability Overview

Category: Broken Access Control Type: Insecure Direct Object Reference (IDOR)

Severity: High CVSS v3.1 : 7.5 Vector : AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Technical Analysis

During reconnaissance, I identified a Live Chat transcript download feature. The request responsible for retrieving transcripts contained a numeric parameter that directly referenced the file identifier:

download-transcript=2

Because the identifier was predictable and exposed to the client, it suggested a potential object reference weakness.

I intercepted the request using Burp Suite Proxy and sent it to Burp Repeater for controlled manipulation. By modifying the parameter value from:

download-transcript=2 → download-transcript=1

the server returned a transcript belonging to a different user, without any authorization error.

None
Intercepted HTTP request in Burp Suite revealing the transcript download endpoint (/download-transcript/2.txt), where the predictable object reference indicated a potential authorization flaw.
None
I sent the request to Burp Suite Repeater and changed the object reference from 2.txt to 1.txt, resulting in unauthorized access to another user's chat transcript and exposure of sensitive credentials.

Root Cause

The backend failed to validate whether the authenticated user was authorized to access the requested transcript. Authorization decisions were implicitly based on client-provided identifiers rather than server-side ownership checks.

Impact

An attacker could:

  • Access private chat transcripts of other users
  • Enumerate and download sensitive data at scale
  • Violate data confidentiality and privacy requirements

Remediation

  • Enforce strict server-side authorization checks for every object request
  • Ensure requested resource ownership matches the authenticated user
  • Avoid exposing sequential or predictable object identifiers

Scenario 2: Method-Based Access Control Bypass

Vulnerability Overview

Category: Broken Access Control Type: Improper Authorization Enforcement

Severity : High CVSS v3.1 : 8.8 Vector : AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Technical Analysis

While testing administrative functionality, I attempted to access an endpoint responsible for privileged user actions. The initial request returned a:

401 Unauthorized

Rather than assuming the endpoint was secure, I analyzed how the server processed the request internally. I sent the intercepted request to Burp Repeater and modified the HTTP method from:

POST → GET

Additionally, I tested alternative routing behavior using headers such as:

X-Original-URL

The modified request was processed successfully, and the restricted action (user promotion) was executed.

None
Administrative request captured and modified in Burp Suite Repeater by changing the username parameter from carlos to wiener to evaluate access control enforcement for user privilege modification.
None
I modified the HTTP request method from POST to GET in Burp Suite Repeater to test method-based access control enforcement, resulting in unauthorized access to the restricted functionality.

Root Cause

Access control checks were inconsistently applied:

  • Authorization logic was bound to specific HTTP methods
  • Backend routing trusted client-controlled headers without revalidation

Impact

An attacker could:

  • Bypass administrative restrictions
  • Escalate privileges
  • Execute sensitive actions without proper authorization

Remediation

  • Enforce authorization checks independently of HTTP method
  • Validate access rights after request routing
  • Avoid trusting headers such as X-Original-URL unless strictly required and securely implemented

Scenario 3: Multi-Step Process with No Access Control on One Step

Vulnerability Overview

Category: Broken Access Control Type: Inconsistent Authorization in Multi-Step Workflow

Severity : High CVSS v3.1 : 8.8 Vector : AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Technical Analysis

While testing administrative functionality, I analyzed a multi-step process responsible for promoting a user to an administrative role.

The application implemented a confirmation workflow before completing the role upgrade. When clicking "Upgrade user", the application redirected to a confirmation page asking:

"Are you sure?"

None
After authenticating as the administrator, I navigated to the admin panel and initiated a user role upgrade, which triggered a confirmation page ("Are you sure?"); upon selecting Yes, I intercepted and captured the resulting request using Burp Suite for further analysis.
None
I forwarded the intercepted upgrade request to Burp Repeater for detailed inspection, where I observed the authenticated session cookie in the request headers and identified the critical parameters in the request body — specifically action=upgrade, confirmed=true, and the username field — which collectively controlled the role escalation operation.

Instead of assuming that only administrators could execute this step, I tested whether the endpoint independently enforced authorization.

Authorization Testing

I logged out as the administrator and logged in as a normal user (wiener).

I intercepted the login request and copied the session cookie associated with wiener.

None
After authenticating as the standard user wiener, I intercepted the login request and copied the associated session cookie, which I then substituted into the previously captured role-upgrade request in Burp Repeater to evaluate whether the administrative endpoint properly enforced server-side authorization controls.

Next, I sent the previously captured promotion request to Burp Repeater and modified:

  • Replaced the administrator session cookie with wiener's session cookie
  • Changed username=carlos → username=wiener

The modified request became:

POST /admin-roles
Cookie: session=<wiener_session>
action=upgrade&confirmed=true&username=wiener
None
After replacing the administrator's session cookie with wiener's session and modifying the username parameter accordingly, I replayed the POST /admin-roles request in Burp Repeater; the server returned a successful response (HTTP 302 redirect to /admin), confirming that the role-upgrade endpoint failed to enforce proper authorization controls.

I then submitted the request.

The server processed the request successfully and upgraded wiener to administrator.

None
The successful execution of the modified request resulted in the privilege escalation of the non-administrative user wiener, as confirmed by the application's "Lab Solved" notification and administrative access being granted.

This confirmed that the confirmation step (confirmed=true) did not independently validate whether the authenticated user had administrative privileges.

Root Cause

Access control checks were inconsistently applied:

  • The confirmation endpoint did not verify the authenticated user's role
  • The server trusted that only administrators would reach this step
  • Authorization enforcement relied on workflow sequencing rather than explicit role validation

Because the backend failed to revalidate privileges, any authenticated user could invoke the promotion request directly.

Impact

An attacker could:

  • Escalate their own privileges to administrator
  • Promote arbitrary users
  • Gain unauthorized administrative access
  • Fully compromise application control

In real-world systems, this could lead to:

  • Complete account takeover
  • Data manipulation
  • Administrative abuse
  • Severe business impact

Severity: High (Privilege Escalation)

Remediation

Enforce strict server-side role validation on every privileged endpoint

Independently verify user permissions before executing administrative actions

Do not rely on confirmation parameters (e.g., confirmed=true) as authorization controls

Implement centralized authorization middleware to prevent inconsistent enforcement

Every sensitive action must validate the authenticated user's role at execution time.