Why do models miss IDOR issues even when they can read the code?

Why code reading is not the same as proving an IDOR

A model can spot a likely object reference, but IDOR is a question of whether the reference is authorised in context. That means the real answer depends on session state, ownership, role, tenancy, and sometimes workflow history. If those signals are not present in the code slice, the model may correctly identify the endpoint and still miss the vulnerability because the access decision cannot be proven from syntax alone.

That gap is why “I can read the code” is not enough for object-level access review. A route like /invoice/123 is only risky if the application lets the caller reach another user’s object without a valid access check, and that often lives in surrounding functions, middleware, shared libraries, or database filters rather than the line that handles the parameter.

Good IDOR analysis therefore combines code inspection with request flow understanding. The reviewer has to trace where the object identifier originates, how the request is authenticated, what lookup or policy decides access, and whether the same object can be reached through alternate paths such as export jobs, mobile APIs, or bulk endpoints.

Why models miss the proof point even when the pattern is obvious

Models tend to overvalue the visible object reference and undervalue the hidden entitlement evidence. They may identify an ID, uuid, or accountNo parameter, yet still fail to establish whether the handler checks ownership, tenant scope, or function-level permissions before returning the object. In other words, they detect the shape of the request more reliably than the control that governs it.

This is especially common when the codebase separates routing from authorization. The actual decision may happen in a policy layer, ORM scope, decorator, gateway, or helper that is easy for a human to connect but hard for a model to reason about if the call chain is long or the relevant context is split across files. The model then produces a plausible warning, but not a reliable finding.

There is also a reasoning problem. IDOR findings require a counterfactual, the application must be shown to return an object that the caller should not be able to access. Without the surrounding evidence, the model can only say “this might be sensitive,” not “this is unauthorised access.” That distinction matters because false positives rise sharply when the tool cannot follow the full access path.

What reviewers should look for instead of trusting a parameter match

A useful review starts by separating object existence from object entitlement. The key question is not “does the request contain an identifier?” but “what makes this caller entitled to this object and where is that decision enforced?” That usually means checking whether the object is constrained by the authenticated user, tenant, role, or a server-side policy before any sensitive data is returned.

The most reliable signals are inconsistent access checks, direct object lookups without scope constraints, and alternate endpoints that return the same object with weaker validation. Read-side IDORs often appear as silent data exposure, while write-side IDORs show up when an attacker can alter a record they do not own. Both require evidence of missing or bypassable authorisation, not just a parameter that looks guessable.

For broader guidance on object-level access failures in APIs, OWASP API Security Top 10 is the clearest external reference for broken authorisation patterns. In control terms, object access should be enforced server side, not inferred from obscurity or client behaviour, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-207 Zero Trust Architecture.

Risk and Threat Considerations

IDOR becomes dangerous when object references are guessable and the application does not re-check entitlement on every request. The result is direct exposure of records, account takeover paths in some workflows, and lateral movement across tenants or users when the same access pattern is reused elsewhere. Models miss this most often when the vulnerable behaviour sits behind normal-looking business logic rather than an obviously insecure line.

Failure mechanism: The handler resolves an object by identifier before or without a server-side ownership or scope check, so a valid session can be used to retrieve or modify another principal’s data.

Impact: Attackers can enumerate objects, exfiltrate sensitive records, tamper with data, or pivot through adjacent functions that trust the same flawed reference pattern.

Practitioner Guidance

What to verify: Confirm where authorisation is enforced for the object, not just where the parameter is parsed. A finding is strongest when you can show the lookup path, the access decision, and the returned record all in one trace.

Common mistake: Treating a guessable identifier as the vulnerability instead of proving that the server returns data the caller is not entitled to see. Guessability matters, but the control failure is the missing entitlement check.

Practitioner takeaway: Use model output as a lead, then require concrete proof of server-side object entitlement before calling something IDOR. If you cannot demonstrate that proof path, you have a hypothesis, not a security finding.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why do API keys create governance issues even when they are easy to issue?
• Why do unverified contracts attract attackers even though the code is harder to read?
• Why do identity exposures remain risky even after code issues are patched?