When a system trusts the presence of a credential instead of verifying the intent behind it, authentication becomes indistinguishable from authorization.
Session identifiers are guessable, fixable, or replayable — identity without integrity
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.
Both trust identifiers without verification — IDOR trusts the resource ID, phantom sessions trust the session ID
Weak session management makes CSRF more exploitable — if sessions are predictable, forged requests gain authenticated context
Year
2001–2008
Context
The web was stateless. HTTP had no memory. When applications needed to know who was logged in, developers invented session management — store a token in a cookie, look it up on the server. The token was the entire proof of identity. If you had the token, you were the user. The question nobody asked: how hard is the token to guess?
Who Built This
Web developers building shopping carts, admin panels, and membership sites. The frameworks of the era — PHP 4, Classic ASP, early Java Servlets — provided session primitives, but the defaults were weak and the documentation was sparse on threat modeling.
Threat Model at Time
Username and password on the login form. SSL on the login page only (not the rest of the site). Session cookies transmitted in plaintext on every subsequent request.
Why It Made Sense
Sessions were a solved problem — session_start() worked. The framework handled the cookie. The developer focused on business logic. Nobody expected an attacker to sit on the same network and read cookies in transit, or to predict session IDs by observing the pattern.
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.