Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: 15 previously unknown IDOR vulnerabilities and 93 false positives were found across Claude Code and OpenAI Codex runs, according to Semgrep’s analysis, with the strongest results in simple cases where authorization was missing or localized to one file. The bigger lesson is that context, not syntax, determines whether automated reasoning can safely identify access-control flaws.
NHIMG editorial — based on content published by Semgrep: LLMs evaluating IDOR findings in real-world applications
By the numbers:
- In the first study, 78% of Claude's IDOR findings were false positives.
- The models found 15 real, previously unknown vulnerabilities, as well as 93 false positives.
- Anthropic Claude Code found 13 true positives and 46 false positives, for a 22% true positive rate.
Questions worth separating out
Q: What breaks when IDOR checks are missing on object identifiers?
A: When an application accepts a user-controlled object identifier without binding it to ownership, tenancy, or role, an attacker can access another principal’s record simply by changing the value.
Q: Why do IDOR findings get noisier when authorization is spread across files?
A: Because the decision is no longer visible in one place.
Q: How can security teams tell whether an IDOR fix is actually complete?
A: A complete fix ties the object being requested to the current user’s entitlement, not just to the object’s existence.
Practitioner guidance
- Inventory every object identifier exposed to users Map routes, GraphQL resolvers, and API parameters that reference user IDs, tenant IDs, invoice IDs, filenames, and other direct object references.
- Trace authorization from entry point to policy decision Review the full request path, including decorators, middleware, inherited base classes, and config files, so you can see where access is actually enforced.
- Write negative tests for cross-object access attempts Add tests that try to fetch another user’s, tenant’s, or organisation’s object by changing only the identifier.
What's in the full report
Semgrep's full research post covers the implementation detail this post intentionally leaves for the source:
- The four-category breakdown of IDOR cases, including which patterns produced the highest true positive rates.
- The exact prompt structure and repeatability observations that shaped the model comparison.
- The table showing per-model true positives, false positives, and category-level performance.
- The code examples that illustrate how authorization hidden in decorators, middleware, or framework hooks affected detection.
👉 Read Semgrep's analysis of how Claude Code and OpenAI Codex perform on IDOR detection →
LLM IDOR detection: where authorization logic still breaks down?
Explore further
02/08/2026 12:37 pm
Authorization visibility is the core failure mode in AI-assisted IDOR detection. The models in this study performed best when the access rule was visible in one place and worst when the policy was distributed, implicit, or hidden behind framework mechanics. That is not a reason to dismiss AI-assisted code review. It is a reminder that detection quality depends on whether the system can reconstruct the full authorization chain, not merely inspect the vulnerable endpoint. Practitioners should treat visibility of policy as a control objective, not a convenience.
A question worth separating out:
Q: Who is accountable when application authorization fails on object access?
A: Accountability sits with the team that owns the application’s authorization model, not just the developers who wrote the endpoint. Where middleware, decorators, and RBAC helpers all contribute to the decision, security and engineering must jointly define, document, and test the effective access path.
👉 Read our full editorial: LLM IDOR detection still fails when authorization spans files
