See exactly how one changed number leaks someone else’s data.

What is an IDOR vulnerability?

An Insecure Direct Object Reference, almost always shortened to IDOR, is one of the most common access-control flaws found in modern web and mobile applications. It happens whenever a system exposes a direct, often predictable, reference to an internal object — an invoice number, an account ID, a file path, a support ticket — and then fails to confirm that the person asking for it is actually allowed to see it. The request itself looks completely normal. There is no malformed input, no injected script, nothing a web application firewall would typically flag. The only thing that changes is a single value in a URL, a hidden form field, or a JSON body, and suddenly the response contains someone else’s data instead of your own.

The reason IDOR keeps appearing on the OWASP Top 10, under the broader Broken Access Control category, is simple: it is easy to introduce and easy to miss. A developer writes a query that fetches a record by its ID, tests it while logged in as themselves, sees the correct result, and ships it. What never gets tested is what happens when the same logged-in user asks for a different ID. If the backend does not compare the record’s owner against the current session, the lookup succeeds for any ID that exists, regardless of who is asking.

A classic example: an online banking dashboard loads statements from /api/statements/8841. Changing that number to 8842 and resending the request, while still logged in as the original user, returns another customer’s statement. No password was cracked, no session was hijacked. The vulnerability was that the server trusted the ID in the request instead of verifying the relationship between the requester and the object. The same pattern shows up in HR portals leaking other employees’ payslips, e-commerce platforms exposing other customers’ orders, and messaging apps that let a user read a conversation thread they were never part of, simply by editing the thread ID.

Fixing IDOR is less about a single patch and more about a habit: every time an object is fetched, updated, or deleted by ID, the server must independently verify ownership or permission, rather than assuming that possession of a valid-looking ID implies the right to use it. In practice this usually means adding a WHERE owner_id = current_user.id style constraint to the query itself, rather than checking permissions separately and then trusting any ID that follows. Where possible, replace sequential, guessable identifiers with random UUIDs so that even if an authorization check is briefly missed, the IDs cannot be enumerated by simply counting upward. Indirect reference maps, where a user-facing token is mapped server-side to the real internal ID, add another layer of friction against casual probing.

Testing for IDOR does not require specialized tooling. Manual testers commonly log in with two separate accounts, capture a request from account A, and replay it with account B’s session while substituting account A’s object ID, watching for data that should have been rejected. Automated static analysis, like the checker above, complements that manual process by scanning source code and API responses for the shape of the problem: identifiers that look sequential, object-lookup functions with no visible authorization clause, and endpoints that accept an ID parameter without any accompanying ownership logic nearby. Neither approach replaces the other. Manual testing confirms real-world exploitability; static review catches the pattern before the code ever reaches production, which is the cheapest place to fix it.