September 22, 2026
IDOR
BROKEN OBJECT-LEVEL AUTHORIZATION
By Sourabh Jala
3 min read
1. Mission Story
You are assessing an authorized training application used by SecureCorp. You have a valid employee account and can view your own profile. During reconnaissance, you notice that the application exposes employee identifiers and that profile data appears to be selected using an employee ID. Your task is to determine whether the server enforces object-level authorization when a different employee ID is requested.
2. Stage One — Reconnaissance
Begin at the login interface. In the supplied lab evidence, the page source contains a commented line that exposes training credentials. This is intentionally included in the vulnerable lab.
1. What credentials are exposed in the supplied source screenshot?
2. Why is placing credentials in client-side source code a security concern?
3. Stage Two — Establish the Baseline
After authentication, establish what a normal employee can legitimately access. The dashboard exposes Directory, Support, and Profile functions.
3. Which three major functions are visible on the dashboard?
4. Which function is most relevant to testing object-level authorization, and why?
4. Stage Three — Find the Target Object
Use the Employee Directory to search for the administrator. Record the identifier returned by the application. Do not assume that knowing an identifier grants permission to access its associated record.
5. What administrator employee ID is shown?
6. What security assumption would be unsafe if the application treated this ID as sufficient authorization?
5. Stage Four — Capture Your Own Profile Request
Open your own profile and identify the employee ID used by the profile functionality. Capture the request in Burp Suite. Record the parameter name and its original value.
7. What is the profile endpoint/path?
8. What parameter carries the employee ID?
9. What is your original employee ID?
6. Stage Five — Authorization Test
In the authorized training environment, modify only the employee/object identifier so that it references the administrator record discovered in the directory. Replay the request and compare the response with your baseline.
10. What exact value did you replace, and what value did you substitute?
11. What HTTP status code did the modified request return?
12. Did the server return the administrator's profile data? Explain the evidence.
7. Impact Evidence
The supplied lab evidence shows that the modified identifier results in the administrator profile being displayed, including payroll information and an internal security note containing the lab flag.
13. List the sensitive fields exposed by the administrator profile.
14. What makes this an IDOR/BOLA vulnerability rather than an authentication bypass?
8. Advanced–Medium Questions
15. Would replacing employee IDs with UUIDs alone fix the vulnerability? Justify your answer.
16. Write the authorization decision the server should make before returning an employee profile.
17. How could predictable IDs increase the practical impact of this vulnerability?
18. What defense-in-depth controls could reduce exposure if an authorization bug occurs?
9. Finding Summary
10. Remediation
Enforce authorization server-side for every object retrieval.
Verify that the authenticated user is allowed to access the requested employee record.
Use role/resource-based access-control policies for privileged records.
Return only the minimum fields required by the requesting function.
Log and investigate repeated cross-object access attempts.
Treat random or opaque identifiers as defense-in-depth, never as the authorization mechanism.
11. Submission Checklist
☐ Credential-source evidence reviewed
☐ Dashboard baseline captured
☐ Administrator employee ID recorded
☐ Original profile request captured
☐ Modified object identifier documented
☐ Administrator response screenshot attached
☐ Impact and remediation questions completed
☐ Flag recorded exactly