Insecure Direct Object Reference (IDOR)

Description

Insecure Direct Object Reference (IDOR) is a type of access control vulnerability that occurs when an application directly uses user-supplied input to access internal objects (e.g., database entries, files, or other resources) without proper authorization checks. In other words, the application references an object (like a record in a database) by a parameter (for instance, a numeric ID) that a user can manipulate. If there is no robust mechanism to verify that the user has permission to access or modify that particular object, the door is left open for attackers to escalate privileges or view and edit data they should not have access to.

IDOR often stems from insufficient or missing access control logic. Applications may assume that if someone has a valid session or is already authorized at a certain level, all object references they provide must be valid for them. This assumption fails when attackers deliberately change parameters and gain access to resources belonging to other users or system records that should be restricted.

Examples

Changing User Account IDs

Suppose a web application profile management page uses a URL like:

https://example.com/user/profile?id=12345

The application retrieves user details for the user with ID 12345 and displays them. If there is no verification that the logged-in user actually owns or has the right to access user 12345's data, an attacker could change this parameter to another ID:

https://example.com/user/profile?id=67890

Potentially revealing or allowing edits to another user's profile.

Direct File Reference

An application might store documents in a system accessible by references like:

https://example.com/documents?file=invoice_12345.pdf

If the application fails to validate ownership or permissions, a malicious user could modify the file name parameter to access another user's file, e.g.:

https://example.com/documents?file=invoice_67890.pdf

They might gain access to sensitive information, violating data privacy and confidentiality.

Elevation of Privileges

In some advanced IDOR scenarios, attackers may also manipulate object references to escalate privileges. For instance, changing a role ID or user group ID within a request that updates account data could grant admin-level access if the application does not validate permissions.

Remediation

  1. Implement Strict Access Control Checks

    • Always validate that the current user is authorized to access or modify the specific resource.
    • Access control logic should be performed server-side, not solely in client-side code or session variables.

  2. Use Indirect References

    • Instead of exposing internal identifiers (e.g., database keys or sequential IDs), map them to unique tokens or opaque references.
    • This prevents attackers from guessing internal resource IDs and eliminates direct object references in user-visible parameters.

  3. Parameter Validation

    • Where direct IDs are necessary, perform checks to confirm that the resource requested belongs to the current user (or that the user has the correct privileges for that resource).
    • Do not rely on hidden form fields or client-side mechanisms for validation—these can be tampered with.

  4. Secure Coding Practices

    • Adopt frameworks and libraries that provide built-in access control mechanisms.
    • Follow the principle of least privilege, granting each user or role only the minimum permissions needed to perform their actions.