What is IDOR?

IDOR stands for Insecure Direct Object Reference. The vulnerability occurs when an application uses a client-controlled object identifier without checking permission for the particular object and operation. An authenticated user may thereby read, change or delete another person's or tenant's data.

How does an IDOR vulnerability arise?

An endpoint such as GET /api/orders/4711 returns an order. If changing the ID to 4712 returns someone else's order, the server trusts the reference rather than making an authorization decision. Correct authentication is insufficient: it establishes who is making the request, while authorization must decide whether that identity may perform this operation on this object.

The flaw often exists when the interface displays only a user's own records but the API accepts any valid ID. Hidden buttons and JavaScript checks are not server-side access control.

Where are object identifiers found?

Read access is not the only concern. Update, delete, export, share, comment, status transitions and bulk operations each need a check. Child objects must belong to the expected parent and tenant as well.

What impact can IDOR have?

Individual records may expose personal or confidential information. Enumerable identifiers can enable export of an entire customer dataset. Write access leads to altered orders, unauthorized approvals, deleted files or account takeover. Access to administrative objects may produce vertical privilege escalation. Severity and scope therefore depend on object, operation and scalability, not only whether an ID can be guessed.

How do IDOR and broken access control differ?

Broken access control is the broad weakness class. IDOR is the case in which a manipulated reference to another object is accepted. Missing function permission, forced browsing and incorrect CORS are other access-control issues. In modern OWASP terminology, IDOR is often described as Broken Object Level Authorization (BOLA), particularly for APIs.

How is IDOR prevented?

1. Check every operation: Evaluate object, user, role, tenant and requested action server-side.
2. Load through relationships: Instead of Order::find($id), conceptually select only from currentUser->orders().
3. Centralize: Apply policies or authorization middleware consistently with denial as the default.
4. Prevent mass assignment: Do not accept owner, role or tenant fields directly from a request.
5. Classify indirect IDs correctly: UUIDs impede enumeration but do not replace a check.
6. Monitor: Detect many failed object accesses and sequential queries without treating monitoring as the primary control.

Code example: load globally or within the user's scope

Vulnerable:

public function show(string $id)
{
    // Every existing order is reachable through its ID
    return Order::findOrFail($id);
}

Safe through the authorized relationship:

public function show(Request $request, string $id)
{
    return $request->user()
        ->orders()
        ->whereKey($id)
        ->firstOrFail();
}

For more complex rules, route model binding can load the object and a Laravel policy can additionally evaluate action, role and tenant. A UUID does not remove the need for authorization.

How is IDOR tested?

A robust test uses at least two accounts with different data and, where relevant, roles or tenants. Testers inventory references and repeat reads, changes and deletion with swapped IDs, tokens and parent objects. Batch endpoints, exports, mobile APIs and alternate HTTP methods matter too. Automation finds sequential IDs, but business relationships and indirect references usually need manual analysis. Only the agreed minimum of production data should be retrieved to prove the issue.