Insecure direct object reference: change the ID, get someone else's data

Prevention follows the OWASP IDOR Prevention Cheat Sheet.

• Changing a number in the address. /account/orders/58213 shows any order once the number is changed.
• Changing a hidden form field. A profile update sends user_id=774; sending another value edits another profile.
• Downloading by file name. /files/statement-2026-09.pdf serves whoever asks, because the folder is not tied to an account.
• Acting, not only reading. Cancelling, refunding or deleting by identifier is the same flaw with worse consequences.
• Moving up, not across. Changing a role or account type field reaches administrator functions; this is vertical privilege escalation.

Reading another user's data is horizontal privilege escalation; reaching functions above your role is vertical. Both are covered on broken access control.

Applications are usually built screen by screen: the page that lists a user's orders shows only their orders, so the page that shows one order seems safe. But the second page can be called directly with any identifier, and if it trusts the identifier the protection on the first page means nothing.

Sequential numbers make the flaw easy to find, but random identifiers do not fix it. A long random ID only hides the object; once it leaks through a shared link, a log or another response, the missing check is just as exploitable.

Automated scanners rarely find it, because a response with another user's data looks like a normal successful response. The reliable method is to test with two accounts: sign in as one, record every request that carries an identifier, then replay them as the other and see what comes back.

In logs, IDOR probing shows as one account requesting many identifiers in sequence, or identifiers that belong to other accounts. That pattern is worth an alert; it is also why limits on how many objects one user may request per minute make bulk extraction slower. The same testing approach applies to APIs; see API security testing.

1. Check ownership on every request that names an object. On the server, for reads and for every action, not only on the screen that lists objects.
2. Look objects up through the user. Query the current user's orders for this ID, rather than any order with this ID.
3. Centralise the check. One authorisation layer that every handler uses is easier to get right than a check in each handler.
4. Deny by default. A new endpoint should refuse until someone writes down who may use it.
5. Use random identifiers as an extra layer. They slow guessing; they never replace the check.
6. Test with two accounts in every release. Make cross-account access part of the regular test plan.

Nothing that fixes it. A request for invoice 1042 has the same shape whether its owner sends it or a stranger does; telling the two apart needs the application's data about who owns what. A request filter does not have it.

Rate limits can make walking through thousands of identifiers slower and noisier, which shortens how long a flaw goes unnoticed. The flaw itself stays until the ownership check is written.