Overview
IDOR / BOLA — accessing objects you shouldn't by manipulating references — is one of the most common and rewarding bug bounty vulnerability classes. This lesson covers the concept.
Learning objectives
- Define IDOR / broken object-level authorization.
- Explain why it is so common and valuable.
- Frame safe, in-scope testing for it.
Core concept
IDOR (Insecure Direct Object Reference) / BOLA (Broken Object-Level Authorization) occurs when an application returns or acts on an object based on a reference (an ID, key, or filename) without verifying the requester is authorized for that specific object (from the web-security authorization and API modules). By changing the reference (e.g. an id in a request), an attacker can access other users' objects. It is extremely common — especially in APIs — and often high-impact (mass data access), making it a top bug bounty target. It is tested safely using the researcher's own test accounts.
How it works
An endpoint like GET /api/invoices/{id} should verify the requester owns invoice {id}. If it fetches the object solely from the reference without an ownership check, changing {id} reaches another user's object — an IDOR/BOLA flaw. The researcher tests for this safely: using two of their own test accounts (A and B), authenticating as A and attempting to access B's object by its reference. If A can access B's object, the flaw is confirmed — using only the researcher's own test data, never real users'. The impact (any user can access others' objects) is documented with minimal, redacted proof.
Practical example
Testing an in-scope API with two test accounts, the researcher (as test user A) requests an invoice belonging to test user B by changing the id in the request — and receives B's invoice, confirming a BOLA/IDOR flaw (no ownership check). They document it with the reproduction (using only their own test accounts) and redacted proof, and note the impact (any user could access others' invoices). Because they used their own test accounts, no real user's data was accessed — a responsibly-tested, high-value finding.
Cybersecurity relevance
IDOR/BOLA is consistently among the most common and highest-value bug bounty findings — especially in APIs — because it is widespread and can expose or modify large amounts of other users' data by simply iterating references. It maps directly to the web-security object-level-authorization and API-security lessons. Critically, it is tested safely using the researcher's own test accounts (A/B), never real users' objects, per program rules and ethics. Findings drive the fix: per-object ownership/permission checks. It is a cornerstone of authorization testing.
Common mistakes
- Testing IDOR against real users' objects instead of the researcher's own test accounts.
- Only checking authentication, not per-object authorization.
- Assuming unpredictable IDs prevent IDOR (obscurity isn't authorization).
Key takeaways
- IDOR/BOLA is accessing objects you shouldn't by manipulating a reference, because the app doesn't verify per-object authorization — common (esp. in APIs) and high-impact.
- Test safely with two of the researcher's own test accounts (access A→B's object by reference), never real users' objects.
- It maps to the web-security object-level-authorization/API lessons; findings drive per-object ownership/permission checks — a top bug bounty target.
Check your understanding
- What is IDOR/BOLA, and why is it so common and valuable in bug bounty?
- How is IDOR tested safely using the researcher's own test accounts?