Insecure Direct Object Reference (IDOR) in JavaScript

This example demonstrates an Insecure Direct Object Reference (IDOR) vulnerability in JavaScript and how to mitigate it. IDOR vulnerabilities occur when an application uses direct references to internal implementation objects without proper authorization checks, allowing attackers to access or manipulate data they shouldn't be able to.

Concepts Behind IDOR

IDOR vulnerabilities arise when an application uses user-supplied input to directly access objects. For instance, if a URL like `/users/123` allows access to user data, and an attacker can change `123` to another user's ID (e.g., `/users/456`), they can potentially access that user's information without proper authorization. This happens because the application isn't verifying if the currently authenticated user is authorized to access the requested object.

Vulnerable Code Snippet

This code is vulnerable because it directly uses the `userId` from the URL without checking if the logged-in user has permission to view the data associated with that `userId`. An attacker could simply change the `userId` parameter in the URL to access another user's data. The API endpoint `/api/users/${userIdFromURL}` is the critical point of vulnerability.

// Vulnerable code (DO NOT USE IN PRODUCTION)

// Assume user IDs are stored in local storage after login
const userId = localStorage.getItem('userId');

// Function to fetch user data based on ID from URL parameter
function getUserData() {
  const urlParams = new URLSearchParams(window.location.search);
  const userIdFromURL = urlParams.get('userId');

  // INSECURE: Directly using the user ID from the URL without authorization checks
  fetch(`/api/users/${userIdFromURL}`) // Vulnerable endpoint
    .then(response => response.json())
    .then(data => {
      // Display user data
      document.getElementById('userData').innerText = JSON.stringify(data, null, 2);
    })
    .catch(error => {
      console.error('Error fetching user data:', error);
      document.getElementById('userData').innerText = 'Error fetching user data.';
    });
}

// Call the function to fetch user data on page load
getUserData();

Explanation of the Vulnerability

The `getUserData` function fetches user data based on the `userId` obtained from the URL parameters. Critically, it doesn't verify if the currently authenticated user (identified by `localStorage.getItem('userId')`) is authorized to view the data for the `userId` extracted from the URL. This allows an attacker to manipulate the URL (e.g., by changing `userId=123` to `userId=456`) and potentially gain unauthorized access to another user's data.

Mitigation: Secure Code Snippet

This code mitigates the IDOR vulnerability by adding an authorization check. Before fetching the user data, it compares the `userId` from the URL with the `loggedInUserId` stored in local storage. If they match, it means the user is trying to access their own data, and the request is allowed. If they don't match, the request is denied, preventing unauthorized access. This is a simple example; more complex authorization schemes might be needed depending on the application's requirements.

// Secure code (Use this in production)

// Assume user IDs are stored in local storage after login
const loggedInUserId = localStorage.getItem('userId');

// Function to fetch user data based on ID from URL parameter
function getUserData() {
  const urlParams = new URLSearchParams(window.location.search);
  const userIdFromURL = urlParams.get('userId');

  // SECURE: Check if the logged-in user is authorized to access the requested user's data
  if (loggedInUserId === userIdFromURL) { // Only allow access to own data
    fetch(`/api/users/${userIdFromURL}`) // Secure endpoint
      .then(response => response.json())
      .then(data => {
        // Display user data
        document.getElementById('userData').innerText = JSON.stringify(data, null, 2);
      })
      .catch(error => {
        console.error('Error fetching user data:', error);
        document.getElementById('userData').innerText = 'Error fetching user data.';
      });
  } else {
    console.warn('Unauthorized access attempt.');
    document.getElementById('userData').innerText = 'Unauthorized access.';
  }
}

// Call the function to fetch user data on page load
getUserData();

Real-Life Use Case

Consider a social media platform where users can view their profiles by visiting a URL like `/profile?id=123`. Without proper authorization checks, an attacker could change the `id` parameter to another user's ID and potentially view their private information, such as posts, messages, or personal details. Similarly, in an e-commerce application, if users can manage their orders through URLs like `/orders/456`, an attacker could modify the `456` to access another user's order history, potentially gaining access to sensitive information like addresses and payment details.

Best Practices

• Always implement authorization checks: Verify that the currently authenticated user has the necessary permissions to access the requested object before granting access.
• Use indirect object references: Instead of exposing internal IDs directly in URLs or requests, use a mapping or UUIDs to obscure the actual object identifiers.
• Implement access control lists (ACLs): Define granular permissions for each object, specifying which users or roles have access to them.
• Regularly audit your code: Conduct security audits to identify and address potential IDOR vulnerabilities.

Interview Tip

When discussing IDOR vulnerabilities in an interview, emphasize the importance of authorization checks and secure object references. Explain how IDOR vulnerabilities can lead to sensitive data exposure and potential account compromise. Be prepared to describe real-world examples and mitigation strategies, such as using parameterized queries, implementing ACLs, and conducting regular security audits.

When to Use Them

Authorization checks should be used on every action where a user is requesting data or performing an action on a resource. This isn't limited to user IDs. For instance, in a document management system, authorization checks should ensure that the user requesting the document has permissions (view, edit, delete) for that specific document. The authorization logic should be consistent across all application layers.

Alternatives

Instead of directly exposing internal IDs, consider using GUIDs/UUIDs. Also, consider using a role-based access control (RBAC) system, where users are assigned roles with specific permissions.

Pros

Properly implemented authorization prevents unauthorized access to resources. Indirect references (e.g., UUIDs) make it difficult for attackers to guess valid resource identifiers.

Cons

Implementing robust authorization logic can increase development complexity and overhead. Incorrect or incomplete authorization checks can still leave the application vulnerable. Over-engineering authorization can also lead to performance bottlenecks.