Glossary · Security
IDOR
Also called: Insecure Direct Object Reference, insecure direct object references, BOLA, broken object level authorization
Definition
Insecure Direct Object Reference, an access-control flaw where changing an ID in a request lets a user read or modify another user's data.
IDOR (Insecure Direct Object Reference) is a vulnerability where the application uses an identifier from the request, such as /api/orders/1043, to fetch a record, but never checks that the logged-in user is allowed to access that record. Change the ID to 1044 and you get someone else’s order. It falls under A01 Broken Access Control in the OWASP Top 10 2021, and the OWASP API Security Top 10 calls the same problem Broken Object Level Authorization (BOLA).
Example
Alice is logged in and sees her order:
GET /api/orders/1043
Authorization: Bearer <alice-token>
She changes the number:
GET /api/orders/1044
Authorization: Bearer <alice-token>
If the response is 200 with Bob’s address and items, the endpoint authenticates the user but does not authorise access to the specific object. Hard-to-guess UUIDs make guessing harder but do not fix the flaw; IDs leak through URLs, logs and shared links.
What a tester checks
Create two test users, each owning their own data, then use user A’s credentials against user B’s objects on every endpoint and method: read, update, delete, and nested routes such as /users/{id}/invoices. This is easy to automate. In Playwright:
import { test, expect, request } from '@playwright/test';
test("Alice cannot read Bob's order", async () => {
const alice = await request.newContext({
baseURL: process.env.API_URL,
extraHTTPHeaders: { Authorization: `Bearer ${process.env.ALICE_TOKEN}` },
});
const res = await alice.get(`/api/orders/${process.env.BOB_ORDER_ID}`);
expect([403, 404]).toContain(res.status());
await alice.dispose();
});
Both 403 and 404 are acceptable; many APIs return 404 so they do not even confirm the record exists. Also check:
- IDs in request bodies and query strings, not just the path.
- Write operations, where an IDOR lets a user change or delete data.
- Bulk and export endpoints that accept lists of IDs.
- Tenant boundaries in multi-tenant systems.
Why it slips through
Functional tests usually log in as one user and use that user’s own data, so the authorisation check is never exercised. IDOR is found by asking “what if this ID belonged to someone else?” for every endpoint. Only run these tests against systems you are authorised to test.