概要
IDOR — Insecure Direct Object Reference, recently rebranded as Broken Object-Level Authorization (BOLA) in the OWASP API Top 10 — is the single most common API vulnerability and the one most APIs are designed to make easy. The framework gives you a router: `GET /api/orders/:id`. The framework gives you an ORM: `Order.findByPk(req.params.id)`. The framework gives you authentication middleware: `requireUser`. The combination feels secure — the user is logged in, the data exists. The missing piece is the third question: is this user the owner of this order? Most teams add that check eventually. Most do not add it everywhere.
仕組み
IDOR appears when authorization is tied to knowing an object ID rather than proving ownership or permission. Attackers can use predictable or discoverable identifiers to access another user's data.
被害範囲
Mass data exfiltration. Every user's data — orders, messages, profile info, uploaded files, billing records, internal notes. In B2B SaaS, cross-tenant access often follows: the IDOR exposes data not just from one other user but from one other org. Write-side IDOR is worse: modifying others' data, deleting accounts, transferring resources, escalating roles. Compliance impact for any service handling regulated data (HIPAA, GDPR, PCI) — IDOR breaches are frequent regulator-attracting events.
// what fixvibe checks
What FixVibe checks
FixVibe checks this class with verified-domain active testing that is bounded, non-destructive, and evidence-driven. Public reports describe the affected surface and remediation. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
鉄壁の防御
Authorize every object access. The server-side check is always 'does this user own (or have access to) this object' — implemented at the data-access layer, not just at the auth gate. The cleanest pattern: every database query that touches user-scoped data includes the ownership predicate by default. ORM scopes that automatically filter by `currentUser.id` or `currentOrg.id` make this the path of least resistance. Postgres Row-Level Security policies are the strongest version — the database itself enforces ownership and your application code can't forget. For mass-assignment defense, accept only the fields your endpoint is designed to update; ignore everything else (use a strict input schema with Zod, Yup, or class-validator). Use opaque IDs (UUIDs, ULIDs) — they don't fix the vulnerability but they slow opportunistic exploitation. Finally, write integration tests that authenticate as user A and assert user B's data returns 404. Make it part of the test fixture; bake it into CI.