Overview
At the core of authorization is object ownership — whether the application verifies that a requester owns or may access the specific object they act on. This lesson focuses on testing object-ownership enforcement.
Learning objectives
- Define object ownership in authorization.
- Explain testing ownership enforcement across operations.
- Connect ownership flaws to comprehensive IDOR/BOLA coverage.
Core concept
Object ownership is the relationship that authorization must verify: does the requester own (or have permission for) the specific object referenced? Proper authorization checks ownership on every operation involving an object — not just reads, but updates, deletes, and other actions. An ownership-enforcement flaw (a form of IDOR/BOLA) exists wherever an operation acts on an object by reference without confirming the requester's ownership/permission. Comprehensive testing checks ownership across all operations and object types, since an app might enforce it on some (e.g. read) but not others (e.g. update/delete).
How it works
Using the researcher's own test accounts (A and B), the researcher tests whether ownership is enforced on each operation involving an object: can test user A read, update, or delete test user B's object by referencing it? An application commonly enforces ownership on read but overlooks it on modify/delete operations (or on certain object types or endpoints), so testing must cover all operations, not just reads. Each operation where A can act on B's object without authorization is a finding. This comprehensive per-operation, per-object-type ownership testing (with the researcher's own accounts) ensures IDOR/BOLA coverage isn't limited to the obvious read case.
Practical example
Testing an in-scope application with two test accounts, the researcher finds that while reading another user's object is properly blocked (ownership enforced on read), deleting it is not checked — test user A can delete test user B's object by referencing it. This ownership-enforcement flaw on the delete operation (a BOLA variant) is a valid, high-impact finding (users can delete others' data), documented with the reproduction (using the researcher's own test accounts) and a fix (enforce ownership on all operations). Comprehensive per-operation testing caught what a read-only check would have missed.
Cybersecurity relevance
Object-ownership enforcement is the crux of authorization, and flaws in it (IDOR/BOLA) are top bug bounty findings. A key insight is that ownership must be checked on every operation and object type — apps frequently enforce it inconsistently (read but not delete, one endpoint but not another), so comprehensive testing across operations finds flaws that read-only testing misses. This deepens the IDOR/BOLA and object-level-authorization concepts (web-security/API modules). Testing uses the researcher's own accounts, in-scope. Findings drive consistent per-object ownership checks on all operations — high-value coverage.
Common mistakes
- Testing only read operations, missing ownership flaws on update/delete/other actions.
- Checking one object type/endpoint but not others.
- Testing with real users' objects instead of the researcher's own test accounts.
Key takeaways
- Object ownership is what authorization must verify — that the requester owns/may access the specific object — on every operation (read, update, delete, etc.), not just reads.
- Ownership is often enforced inconsistently (read but not modify/delete, or some endpoints not others), so test comprehensively across operations and object types with the researcher's own test accounts.
- Ownership-enforcement flaws are IDOR/BOLA findings (top bug bounty value); findings drive consistent per-object checks on all operations.
Check your understanding
- Why must object-ownership enforcement be tested on all operations (not just reads)?
- How does comprehensive per-operation testing catch IDOR/BOLA flaws that read-only testing misses?