A blank response after changing an object ID does not, by itself, show that an API enforces ownership. The ID might not exist, or the request might use the wrong parameter. In a November 2026 FreeBuf article, author 无颜 outlines a controlled way to distinguish those possibilities when testing for insecure direct object references (IDOR).
The approach starts with two accounts you control. Create an object under account A and record its ID. Then, using account B’s separate session, request that known-to-exist object. Keep the sessions isolated so their cookies do not overwrite one another, and use the parameter name observed in a normal request rather than guessing it.
The response determines what you can report:
- B receives A’s object data: This demonstrates unauthorized access in that test. Record minimal evidence and stop rather than browsing more records.
- B receives an empty response: This is consistent with an ownership check, but interpret it in the context of the controlled test. An empty response for a merely adjacent or guessed ID establishes much less, because that ID may not exist.
- The API returns 403 or redirects to login: That shows an authentication barrier at that point. It does not, on its own, establish that an authenticated user cannot access another user’s object.
The article cautions against enumerating IDs. Consecutive numbers may not correspond to existing objects, particularly when a system uses distributed ID schemes; bulk requests can also breach testing rules or burden a service. Its practical lesson is to control the variables: use accounts and data you own, make a small number of authorized requests, and leave the finding inconclusive when the evidence does not support a firmer conclusion.
Original article: FreeBuf.