Lesson 6 of 15

Broken Access Control

Broken access control occurs when applications fail to properly enforce what authenticated users are allowed to do, enabling privilege escalation and unauthorized data access. You will learn horizontal and vertical privilege escalation, insecure direct object references (IDOR), and how to systematically test access control throughout a web application. IDOR vulnerabilities are among the highest-paid findings in bug bounty programs.

Learning Objectives — Deep Dive

Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.

0/4

In plain English

This is asking you to build a clear mental model of the concept — not just memorize a definition, but genuinely understand what it means, why it exists, and how it connects to everything else you are learning. When you can explain "horizontal vs vertical privilege escalation" in your own words to someone who has never heard of it, you have truly learned it.

Why this matters

This objective builds a foundational skill that every security professional uses regularly. Mastering it gives you the vocabulary, mental models, and practical ability to tackle more advanced topics with confidence — and to communicate clearly with both technical and non-technical colleagues.

Real-world analogy

Think of it like learning to drive. You do not need to understand how the engine works to drive safely, but knowing the basics helps you diagnose problems and avoid mistakes that could cause accidents. The same principle applies here — foundational knowledge prevents costly errors.

What you will be able to do

Apply this skill in a real lab environment, explain it clearly to a colleague or client, and use it as a building block for the more advanced techniques that come later in this course.

Beginner tip

Do not try to memorize everything at once. Read through the material once to get the big picture, then go back and work through the lab. The hands-on practice is what makes the concepts stick — passive reading alone will not get you there.

Broken Access Control · Objective 1 of 4

VIDEO

Loading video…

Create two test accounts

In DVWA or a test application that supports user accounts, register two separate accounts: user_a@test.com and user_b@test.com, each with their own password. Create a resource (such as a profile, document, or order) while logged in as user A and note the URL or ID of that resource. The goal is to test whether user B can access or modify user A's resource by manipulating the identifier in the request — this is the core of an Insecure Direct Object Reference (IDOR) vulnerability.

Log in as user A and navigate to the resource you created. Open Burp Suite's Proxy and intercept the HTTP request that retrieves or modifies the resource. Examine the request carefully — look for any parameter that contains a user ID, resource ID, account number, or filename that identifies the specific object being accessed. Common locations include URL path parameters (/api/users/123/profile), query string parameters (?id=456), and POST body parameters. Note the exact parameter name and value for use in the next step.

Identify object references

Analyze the captured request to identify all direct object references — any value that maps to a specific record in the database or file on the server. Common patterns include sequential integers (id=1, id=2), UUIDs, usernames, email addresses, and filenames. Sequential integers are the easiest to exploit because you can simply increment or decrement the value to access adjacent records. UUIDs are harder to guess but are still vulnerable if the application does not enforce authorization checks — guessing is not the only attack vector.

Replace with user B identifiers

Log out of user A and log in as user B. Replay the captured request in Burp Suite's Repeater, replacing user A's resource ID with user B's credentials in the Cookie or Authorization header, but keeping user A's resource ID in the parameter. If the application returns user A's data to user B, you have confirmed an IDOR vulnerability — the application is authorizing access based on the object ID alone, without verifying that the requesting user owns or has permission to access that object. This is a broken access control vulnerability (OWASP A01:2021).

Previous: Authentication Flaws Next Lesson