← All articles

IDOR and Broken Access Control: Authentication Isn't Enough, You Need Authorization

5 September 2026

IDOR and Broken Access Control: Authentication Isn't Enough, You Need Authorization

IDOR (Insecure Direct Object Reference) is when a user, with a valid session, accesses a resource that does not belong to them. The classic example: changing the number in account?id=1023 to 1024 to view someone else’s invoice. The attacker cracks no password and steals no session; they simply change an identifier. IDOR is the most common member of the “Broken Access Control” family, which has long topped the OWASP Top 10.

Authentication ≠ authorization

Two concepts that are frequently confused:

  • Authentication: “Who are you?” — that the user has logged in.
  • Authorization: “Are you allowed to do/see this?” — that you have permission over the requested resource.

IDOR appears where authentication is correct but authorization is missing. The user has logged in, but the server does not check whether the requested id actually belongs to them.

How it’s detected

  • Predictable identifiers: Sequential numeric ids (1023 → 1024) invite manipulation.
  • Ids everywhere: Not just in the address bar; also in hidden form fields, API calls like PATCH /api/orders/1024, and JSON bodies.
  • Horizontal and vertical access: Horizontal (another equivalent user’s data) and vertical (a normal user reaching an admin function) both belong to this family.

A practical test: open two accounts (A and B), log in as A, and request a resource id belonging to B. If B’s data is returned, IDOR exists.

Prevention: object-level authorization

  1. Verify on the server, based on the session user. Do not trust the incoming id; ask “does this order really belong to the session owner?” every time.
  2. Derive the resource from the session where possible.
  3. Use a central authorization layer; scattered checks lead to forgetting one.
  4. Unpredictable identifiers (UUIDs) help but are not sufficient on their own.
  5. Default to deny.

Summary

IDOR is a logged-in user changing an identifier to reach someone else’s data, and its root cause is missing authorization. The fix is clear: on every resource access, verify on the server that the session user is genuinely authorized; default to deny; and derive the resource from the session where possible.

Sources: OWASP: Broken Access Control (A01:2021), OWASP Authorization Cheat Sheet.

Authorization flaws like IDOR depend on business logic. CyberTestify’s active verification package runs controlled authorization tests on discovered endpoints.