What is IDOR? The vulnerability scanners always miss

Ask a room of security engineers which vulnerability scares them most and the answer is rarely the flashy one. It is IDOR: Insecure Direct Object Reference. Simple to understand, trivial to exploit, invisible to every scanner, and devastating in production.

What IDOR actually is

Your application references objects by an identifier: invoice 1042, document 88, order 55601. IDOR is when the application checks that you are logged in, but never checks that the object you are asking for belongs to you. Change one number in the URL or the API request, and you are reading a stranger's data.

Why scanners cannot find it

A scanner can see that /api/v2/invoices/1042 returns 200. It cannot see that invoice 1042 belongs to a different customer, because that requires understanding who you are, who owns the object, and what "wrong" looks like. This is the cleanest possible argument for manual testing: a junior tester with two accounts and ten minutes finds IDOR that a ten-lakh scanner reports as nothing.

Every "massive data breach via API" headline you have read was, more often than not, an IDOR with a for-loop around it.

The patterns, so your engineers can recognize them

• Sequential IDs: /invoices/1042, /invoices/1043... enumeration is a for-loop away. Use UUIDs and you raise the cost, though authorization is still required
• Trust in the client: totals, prices or permissions accepted from the request instead of the server session
• Mass assignment: sending {"role": "admin"} in a profile update that the backend happily saves
• Hidden but reachable: admin routes removed from the UI but still routed in the backend
• Referential leaks: object A contains a link to object B that was never authorization-checked

The fix, stated once and stated clearly

Every request for an object must answer one question server-side: does the authenticated principal own or have rights to this exact object? Not "is the user logged in." Not "did the UI show them this link." Ownership, checked on the server, on every access, as close to the data layer as possible. Centralize it in middleware so no endpoint can forget it.

How we test for it

Two accounts, three roles where possible, and a patient walk through every business flow comparing what each account can reach. Then chaining: does the low-privilege finding combine with something else to cross a boundary that matters? That chaining, deciding whether a low-severity gap is actually a critical exposure, is the judgment layer tools do not have.

IDOR is a flagship example of why we built HexaSentra manual-first. Read how our engagements run, or book a scope call and we will walk your authorization model with you.