# IDOR

**Description:**\
Insecure Direct Object References (IDOR) occur when an application exposes a reference to an internal object, such as a file, database record, or URL, without proper access control. This allows attackers to manipulate the reference to gain unauthorized access to data or functions.

**Example with Scenario:**\
Imagine an e-commerce website where users can view their order details by accessing a URL like `http://example.com/order?id=1234`. If the application does not verify whether the authenticated user is authorized to view order `1234`, an attacker could change the `id` parameter to access other users' orders.

**Payloads and Test Cases:**

1. **Basic IDOR to Access Unauthorized Data:**
   * URL: `http://example.com/order?id=1234`
   * Payload: Change `id` to another order number, e.g., `http://example.com/order?id=1235`
   * Test Case: Verify if the application allows access to the order details for `id=1235` without proper authorization checks.
2. **IDOR in API Endpoints:**
   * API Request: `GET /api/user/1234/profile`
   * Payload: Change user ID to another user's ID, e.g., `GET /api/user/1235/profile`
   * Test Case: Check if the API returns the profile details for user `1235` without authorization.
3. **IDOR in File Download:**
   * URL: `http://example.com/download?file=report1234.pdf`
   * Payload: Change `file` parameter to another file name, e.g., `http://example.com/download?file=report1235.pdf`
   * Test Case: Ensure that the application prevents unauthorized file downloads by checking proper permissions.
4. **IDOR in User Management:**
   * URL: `http://example.com/admin/user/edit?id=1234`
   * Payload: Change `id` to another user's ID, e.g., `http://example.com/admin/user/edit?id=1235`
   * Test Case: Verify if non-admin users can edit or view details of other users without proper authorization.
5. **IDOR in Account Settings:**
   * URL: `http://example.com/account/settings?id=1234`
   * Payload: Change `id` to another account ID, e.g., `http://example.com/account/settings?id=1235`
   * Test Case: Check if users can access or modify other users' account settings.
6. **IDOR in Deletion Functionality:**
   * URL: `http://example.com/delete?file=1234`
   * Payload: Change `file` parameter to another file ID, e.g., `http://example.com/delete?file=1235`
   * Test Case: Ensure that the application checks for proper authorization before allowing deletion of any resource.

**Mitigation:**

1. **Implement Proper Access Controls:**

   * Ensure that every access to sensitive data or functionality checks if the user has the appropriate permissions.

   ```java
   // Example in Java
   User user = getCurrentUser();
   Order order = orderService.getOrderById(orderId);
   if (!order.getUser().equals(user)) {
       throw new UnauthorizedAccessException();
   }
   ```
2. **Use Indirect References:**

   * Instead of using direct references like database IDs, use indirect references that are mapped to internal objects securely.

   ```java
   // Map indirect reference to internal ID
   String orderRef = "ORD-1234-ABC";
   Order order = orderService.getOrderByRef(orderRef);
   ```
3. **Input Validation and Sanitization:**

   * Validate and sanitize user inputs to ensure they do not contain unauthorized references.

   ```java
   if (!isValidId(orderId)) {
       throw new InvalidInputException();
   }
   ```
4. **Log and Monitor Access:**

   * Implement logging and monitoring to detect and respond to unauthorized access attempts.

   ```java
   // Log access attempts
   logger.info("User {} accessed order {}", user.getId(), orderId);
   ```
5. **Use Frameworks with Built-in Security:**
   * Use security frameworks that provide built-in mechanisms for access control and authorization checks.
6. **Perform Regular Security Audits:**
   * Regularly review and audit your codebase for potential IDOR vulnerabilities and fix them promptly.