What is IDOR?
IDOR stands for insecure direct object reference, an access-control flaw where an application exposes a direct reference to a record, such as an identifier in a URL or form, and then fails to confirm that the logged-in user is allowed to access that specific record. The user is authenticated, but the application never checks authorization on the individual object, so changing the reference reaches data that belongs to someone else.
How the attack works
The classic case is a sequential identifier in a request. A customer viewing their own invoice at a URL ending in a number simply edits that number to a neighboring value and sees another customer's invoice. The same pattern applies to account numbers, document IDs, order references and API paths. Because the request is otherwise normal and comes from a valid session, nothing looks wrong in the logs beyond a user touching records that are not theirs.
Why it is a form of privilege escalation
Reaching another user's data at the same permission level is horizontal privilege escalation, and IDOR is a common vehicle for it. No higher tier of access is gained; the attacker simply acts as a different peer. That distinguishes it from vertical escalation, where a standard user gains administrator rights. In web-application terms, IDOR falls under broken access control, and its API-centric form is often called broken object level authorization.
How to defend against it
The fix is an authorization check on every object access: the server must confirm the current user owns or is permitted to use the requested record before returning it. Hiding or randomizing the identifier is not a fix, because an attacker who ever learns a valid value can still request it; an unguessable reference only raises the effort. Checking ownership server-side, scoping queries to the authenticated user, and enforcing access control consistently across every endpoint are the durable controls.
IDOR on the CompTIA Security+ exam
IDOR appears with the application-attack and privilege-escalation material under SY0-801 objective 2.5. The scenario clue is a user changing a parameter, usually an identifier, and viewing a record that belongs to someone else. Name it as horizontal privilege escalation through an insecure direct object reference, and choose the fix that adds an authorization check on each request, not one that merely obscures or randomizes the identifier.