Insecure direct object references (IDOR)

What it is

IDOR is the bug where the server assumes the client will only ask for objects it is allowed to ask for. It is less about the missing check and more about the missing *ownership model* — the tool treats the ID as a fact, not as a claim to authorize.

Why it matters for MCP

MCP tools often wrap existing APIs that already had authorization baked in at the HTTP layer. When you wrap those APIs into a tool the LLM can drive, the authorization gets re-anchored on whatever credentials the server was given at startup — typically a single service account with broad access. The model can now ask for any object the service account could see, including objects the current end-user should not.

Vulnerable example

@server.tool()

def get_invoice(invoice_id: str) -> dict:

    return db.fetch_one("SELECT * FROM invoices WHERE id = %s", invoice_id)

Secure example

@server.tool()

def get_invoice(invoice_id: str, ctx: Context) -> dict:

    user_id = ctx.principal.user_id  # set from the MCP auth layer

    row = db.fetch_one(

        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",

        invoice_id,

        user_id,

    )

    if not row:

        raise PermissionError("invoice not found or not yours")

    return row

How MCPSafe detects this

We flag database reads that use a tool argument as the primary-key filter without joining to a principal-derived column. This is a heuristic rule — false positives are common, so we surface it as HIGH evidence rather than a certain finding.

See the full threat catalog for every documented detection.

Framework alignment

OWASP LLM Top-10 (2025)

LLM02 — Sensitive Information Disclosure

OWASP Agentic AI Top-10

T03 — Privilege Compromise

AIVSS v0.5

7.1 (HIGH)AIVSS:1.0/S:HIGH/AV:N/AU:L/BR:M/CD:D

Further reading

• CWE-639: IDOR
• OWASP API1: Broken Object-Level Authorization