When a system trusts the presence of a credential instead of verifying the intent behind it, authentication becomes indistinguishable from authorization.
Authentication is checked, but authorization to access a specific resource is assumed from the credential alone
If a system performs a state-changing action because a credential is present — without verifying that the specific request was intentionally initiated by the credential holder — the system trusts authority, not intent.
Every authentication mechanism that attaches credentials automatically recreates this pattern. Cookies gave way to bearer tokens, tokens to API keys, keys to ambient cloud IAM roles. The carrier changes. The assumption does not.
Unguarded memory (1960s) is the physical precursor to IDOR (2000s). Both grant access because an identifier is known, not because access is authorized
Both trust identifiers without verification — IDOR trusts the resource ID, phantom sessions trust the session ID
Exposed credentials enable unauthorized access — a committed API key bypasses all access control
Year
2003–present
Context
Web applications stored data by ID. Every customer had an ID. Every order had an ID. Every document had an ID. The URL showed the ID: /account/1042, /invoice/8837, /document/download?id=553. The application verified that the user was logged in (authentication). It never verified that the logged-in user was authorized to access that specific resource (authorization). Change the number. See someone else's data.
Who Built This
Web developers who confused authentication with authorization. "The user is logged in" meant "the user can access anything." The frameworks provided authentication middleware. They didn't provide per-resource authorization — that was the developer's responsibility, and the developer often forgot.
Threat Model at Time
Authentication was the security boundary. If you had a valid session, you were trusted. The URL was considered an implementation detail, not an attack surface. Nobody expected users to modify the URL manually — after all, the UI only showed links to their own resources.
Why It Made Sense
Sequential integer IDs were database primary keys. Using them in URLs was natural. The application displayed the user's orders — why would it display anyone else's? The developer tested with one user. One user can't access another user's data because the UI doesn't show links to it. The bug only appears when someone types a different number.
This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.
Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.