Documentation / Platform glossary / Insecure Direct Object Reference
An insecure direct object reference occurs when an application accepts an identifier from a request and returns the corresponding record without verifying the caller is entitled to it. The user is authenticated; the flaw is that authorization was never checked for that specific object.
The pattern is simple enough to be easy to miss. A request references a record — in a path, a query parameter, or a request body — and the application retrieves it by that reference. If nothing confirms the record belongs to the caller's tenant or falls within their permissions, changing the reference returns someone else's data.
IDOR is a form of broken object-level authorization, and it is consistently among the most prevalent API vulnerabilities. Its prevalence has a structural cause: authentication is usually handled centrally by middleware, whereas per-object authorization must be applied at every place an object is fetched. Central controls are hard to forget; distributed ones are not.
Two ineffective mitigations are worth naming. Replacing sequential identifiers with unguessable ones (UUIDs) makes discovery harder but leaves the flaw intact — references leak through logs, exports, shared links, and other users' legitimate access. Hiding an action in the interface changes nothing, because the request can be made directly.
The effective mitigation is to make the authorization check unavoidable rather than remembered. Scoping every retrieval to the caller's context so that an unauthorized reference returns nothing is structurally different from adding a check to each handler, because it fails closed when someone forgets.
In a multi-tenant platform, an IDOR is potentially a cross-tenant data exposure — the most serious failure class available, and one that cannot be remediated by rotating credentials.
It is also difficult to detect from the outside. The requests look legitimate and return successful responses, so nothing appears anomalous unless authorization is being verified explicitly.
QueryTek scopes record retrieval at the data layer so a reference outside the caller's tenant returns nothing rather than the wrong record. This makes the boundary structural instead of dependent on a per-handler check. Implementation detail is not published.
