Can IDOR Vulnerabilities Be Found Through Static Analysis? New Python Kernel Aims to Answer the Question

A researcher has developed a static analysis module for detecting Insecure Direct Object Reference (IDOR) vulnerabilities in Python web applications. The tool moves beyond simple heuristics by tracking the relationship between user-controlled identifiers, database objects, and authorization checks. It supports Django, Django REST Framework, Flask, and FastAPI, using a custom taint-tracking system called SIAOD to label data origins. Existing approaches such as OpenAPI specifications, broad AST heuristics, Semgrep, and CodeQL were analyzed and found insufficient for capturing the precise semantics of IDOR. Testing on 150 small repositories yielded 48 true positives out of 112 findings, while analysis of 12 million lines of production code from 15 companies produced only five confirmed issues amid hundreds of false positives caused by authorization logic residing outside handler functions. The work demonstrates both the feasibility and current limitations of deterministic static detection for this vulnerability class.

HabrTranslated from Russian

Read at source

A researcher has released a static analysis module designed to detect IDOR (Insecure Direct Object Reference) vulnerabilities in Python web applications by analyzing data flow rather than relying on heuristics.

The project addresses a long-standing question: whether IDOR flaws can be identified statically by tracing the connection between a user-supplied identifier, the retrieved object, and any authorization check that must dominate the access path.

IDOR occurs when an application exposes direct references to objects without verifying that the current user is authorized to access them. Classic examples include Flask routes that accept an invoice_id parameter and fetch the record with Invoice.query.get(invoice_id) after only a @login_required decorator, allowing any authenticated user to enumerate other users’ invoices.

The new module parses project sources to locate HTTP handlers across Django, DRF, Flask, and FastAPI. It then builds a protocol of inputs, data accesses, and checks for each handler. Values are labeled using the SIAOD system: SUBJECT for the authenticated user, INPUT for ordinary request data, ATTACKER_SELECTED for identifiers that select specific objects, OBJECT for records retrieved from storage, and DYNAMIC for values whose origin cannot be determined statically.

Unlike conventional taint analysis, the engine requires that an authorization check both references the exact OBJECT reached via an ATTACKER_SELECTED identifier and dominates the code path that returns or uses that object. Checks in unrelated branches, checks performed after the object has already been returned, or checks that compare a different object are all rejected.

Evaluation on 150 small open-source repositories produced 112 findings, of which 48 were confirmed true positives. On 15 production codebases totaling 12 million lines, the tool reported 731 findings but only five were genuine; the remainder stemmed from authorization logic implemented in routers, dependencies, or external RBAC frameworks rather than inside individual handlers.

The author concludes that while mathematical tracking of object ownership is possible, real-world authorization patterns frequently place the decisive checks outside the analyzed handler scope, limiting the precision of purely static approaches today.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild