IDOR happens when your API lets a user access resources (profiles, orders, documents) using a predictable ID — and does not verify that the requesting user actually owns that resource. An attacker changes /api/orders/1001 to /api/orders/1002 and reads someone else's order.
Think of it this way
Imagine a hotel where room keys are numbered and any key opens any door if you know the number. You checked into room 101, but you discover that if you type 102 at the lock it opens too. IDOR is that — the door has a number, but no one checks whether you are the guest assigned to it.
Developers often build APIs where objects are referenced by sequential integers or predictable UUIDs: /users/123, /invoices/4567, /messages/89. If the server checks authentication (is this a logged-in user?) but not authorisation (does this logged-in user own object 4567?), any authenticated user can access any other user's data by changing the ID. Attackers automate this by scripting requests with incrementing IDs to harvest data at scale.
Scenario 1
A patient app returns records at /api/patients/{id}. A malicious user discovers their own patient ID is 8841, then iterates from 1 to 10,000 — downloading thousands of other patients' diagnoses, medications, and doctor notes.
Scenario 2
A fintech API exposes account statements at /api/statements/{account_id}. An attacker increments account IDs to download statements for thousands of accounts they do not own.
Scenario 3
An e-commerce API allows cancellation at /api/orders/{id}/cancel with no ownership check. An attacker cancels competitors' orders by iterating through recent order IDs.
Anomira flags when an authenticated user or session accesses a high volume of distinct object IDs in rapid sequence — a pattern consistent with automated enumeration rather than normal usage.
See this attack in your live API traffic
Anomira detects insecure direct object reference (idor) automatically — no configuration needed.