IDOR in a multi-tenant invoice API
Find an object-level authorisation failure in a tenanted API and demonstrate cross-tenant access without touching another real customer.
- Difficulty
- Beginner
- Time
- 35 min
- Tools
- 3
- Walkthrough
- Included
What you are walking into
Spoiler-free by policy. The setting and the class of flaw, never the parameter, the path or the credential.
A billing API serves several tenants from one deployment. Every request carries a valid session for your own tenant, and the application checks that the session is valid on every route. The lab gives you two accounts in two different tenants so the comparison is yours to make, and the whole exercise runs against seeded data inside the sandbox. The interesting question is not whether you are authenticated. It is what the server checks after it decides that you are.
What you will practise
- Separate authentication failures from authorisation failures in a request trace
- Build the two-account comparison that makes an object-level check visible
- Recognise the identifier patterns that make enumeration cheap and the ones that only make it slower
- State the impact in terms of records reachable, not in terms of the identifier being guessable
What this assumes
Prerequisites
- You can send an authenticated API request with a tool of your choice
- You understand what a session cookie or bearer token represents
Tools used
- Burp Suite Community
- curl
- Any HTTP client
Certification objectives
- BSCP-1.2
Are you ready for this one?
One question, answered honestly, tells you more than the difficulty label does.
An API returns 403 for a record belonging to another tenant, but 404 for a record that does not exist. Is that a finding?
- No. The access control is working
- Yes, and it is the same severity as reading the record
- Yes, but as a separate, lower-severity finding: the response difference confirms which records exist
- Only if the identifiers are sequential
Show the answer
Answer: C.
The access control is working. The response difference is a separate issue, an enumeration oracle, and it is worth reporting on its own terms rather than inflating it into a broken access control finding. Getting this distinction right is most of what separates a report that gets triaged from one that gets closed.
How this lab goes
- Completions
- 0
- Median time
- 35 min
- Rating
- Not yet rated
- Ratings
- 0
Median time is the authored estimate. Completion and rating figures are zero because the platform has not launched, and they are shown as zero rather than hidden: an invented statistic on a page like this is worth less than an empty one.
What is behind the sign-in
The sandbox, the guided task list with per-task validation, progressive hints that cost nothing to unlock, and the full text walkthrough. The walkthrough is not published here and will not be: a public walkthrough is a public answer key, and the room stops being worth doing.
Where this sits
Cyber VK Lab Engineering
Pre-publication content owner
Internal ownership label for lab material and walkthroughs.
Updated
[ Related ]
- GlossaryInsecure Direct Object ReferenceAn insecure direct object reference is an access control failure in which an application uses a user-supplied identifier to select a record and does not check that the requesting user is allowed to see that particular record.
- CTF roomLedger DriftA small internal accounting application with a self-service export feature and an authorisation model that was written before the tenanting was.
- GlossaryServer-Side Request ForgeryServer-side request forgery is a vulnerability in which an attacker causes a server to make an HTTP request to a destination the attacker chooses, using the server as the origin of that request instead of their own machine.
- LabBlind SSRF to cloud metadataProve that a server-side request forgery with no visible response can still reach an internal service, and write the finding so a triager cannot close it as informational.
- GlossaryCross-Site Request ForgeryCross-site request forgery is a vulnerability in which a site an attacker controls causes a victim browser to send a state-changing request to a different site where the victim is already authenticated, using credentials the browser attaches automatically.
- ArticleWhy your SSRF report gets closed as informationalMost blind SSRF reports are closed without a payout, and usually for the same three reasons. Here is what a triager is actually looking for, and how to supply it without touching anything you should not.