CWE-639: Authorization Bypass Through User-Controlled Key

The application retrieves a user-related record using a key that is under user control. Although the requester may be authenticated, the authorization process does not properly verify that this user is entitled to access the specific record, allowing the lookup operation to bypass other authorization checks.

The key may be exposed in an HTML form field, a URL parameter, or an unencrypted cookie variable, all of which can be tampered with. If the server accepts the changed value without binding the record to the current user, the attacker may access another user's data. A related manifestation uses sequential or otherwise predictable session identifiers, allowing one user to switch to another user's session and read or modify its data.

This weakness occurs when record retrieval relies on a user-controlled key and authorization does not confirm access to the particular record identified by that key. The key may be exposed through a hidden HTML form field, URL parameter, or unencrypted cookie, making alteration possible. Sequential or predictable session identifiers can produce a related result by enabling access to another user's session. The weakness is introduced during architecture and design, and its likelihood of exploitation is rated high.

Access-control checks for specific user data or functionality can be bypassed. A user may achieve horizontal privilege escalation by viewing or modifying another user's information. If the user-controlled key represents an administrator-status flag, the same weakness can also enable vertical privilege escalation and administrative access.

Apply authorization checks to every data access operation, verifying that the requesting user has sufficient privilege for the specific record being requested. Do not allow users to externally control the key used to look up another user's record, or ensure that tampering is detected. Encryption can make other valid key values more difficult to guess, while associating a digital signature with the key allows the server to verify that it has not been modified.

Automated static analysis, commonly called Static Application Security Testing (SAST), can find some instances by analyzing source or binary code without executing the application. It typically builds data-flow and control-flow models and searches for potentially vulnerable patterns connecting input sources with sinks where data interacts with external components or lower layers. This approach does not guarantee detection of every instance because it is limited to weaknesses whose relevant flows and patterns can be inferred from the analyzed code.

Representative examples, not an exhaustive list, include CVE-2021-36539. An educational application failed to restrict file IDs to a particular user, allowing an attacker to brute-force guess IDs and demonstrating an IDOR-style access control failure.