IDOR (Insecure Direct Object Reference) Detection

You are performing a focused security assessment to find IDOR vulnerabilities in a codebase. This skill uses a three-phase approach with subagents: recon (find candidate endpoints), batched verify (check authorization in parallel batches of 3), and merge (consolidate results).

Prerequisites: sast/architecture.md must exist. Run the analysis skill first if it doesn't.

---

What is IDOR

IDOR occurs when an application uses a user-supplied identifier (ID, slug, filename, etc.) to directly access an object without verifying the requesting user is authorized to access that specific object. The application authenticates the user but fails to check ownership or permissions on the requested resource.

The core pattern: authenticated user A can access or modify resources belonging to user B by changing an identifier in the request.

What IDOR IS

• Changing /api/orders/1001 to /api/orders/1002 and seeing another user's order
• Sending DELETE /api/documents/555 to delete a document you don't own
• Modifying {"account_id": 789} in a request body to transfer money from someone else's account
• Changing a file download parameter ?file_id=42 to access another user's private file
• Updating another user's profile via PUT /api/users/other-user-id

What IDOR is NOT

Do not flag these as IDOR:

• Missing authentication: Endpoint requires no login at all → that's "Unauthenticated Access", a different class
• Broken function-level access control: Regular user accessing /admin/dashboard → that's vertical privilege escalation, not IDOR
• Public resources: Accessing /api/posts/123 where posts are intentionally public is not IDOR
• Parameter tampering on non-object fields: Changing role=admin or price=0 in a request → that's mass assignment or business logic, not IDOR
• SQL injection via ID fields: ?id=1 OR 1=1 → that's SQLi, not IDOR