IDOR: another user’s object, one familiar request
Why signing in does not grant access to every object. A controlled test with two accounts.
Locate the boundary
Authentication establishes who you are; authorization determines what you may do. IDOR occurs when an application accepts an object identifier without checking whether the current user may perform the requested action on that object. An unpredictable identifier does not replace this check.
Create a controlled example
Prepare two authorized test accounts, A and B, with one object each. In a request from account A, substitute the identifier of B’s test object. Record the expected denial and the actual response. Do not test against randomly selected objects belonging to real users.
Check the action, not just the status
A 200 response alone does not prove a vulnerability: the application might return an empty shell. Compare the content and the actual object state. Reading, updating and deleting are separate permissions; protection of one action says nothing about the others.
Fix and retest
The server must check permission for the specific object and action on every request. After remediation, repeat the test across roles and organizations, including alternative API routes. Add a negative test that verifies one user cannot retrieve another user’s object.