What is IDOR?

IDOR stands for Insecure Direct Object Reference. Your app hands the browser a link or API call that points at a specific object — an invoice, a message, a project — usually by ID. If the server checks "is this person logged in?" but never checks "does this person own invoice 124?", a logged-in customer can swap the ID and read another customer's data.

A concrete example

You're logged in as Alice. Your invoice page is:

https://yourapp.com/invoices/123

You change the URL to:

https://yourapp.com/invoices/124

If Bob's invoice loads, that's IDOR. Same pattern on APIs: GET /api/orders/124 with Alice's session cookie returning Bob's order row.

Where OWASP ranks it

IDOR isn't a separate OWASP Top 10 line item — it's a Broken Access Control failure:

• OWASP Top 10 (2021): A01:2021 — Broken Access Control (#1)
• OWASP API Security Top 10 (2023): API1:2023 — Broken Object Level Authorization (BOLA), the API-specific name for the same class of bug

Authentication answers "who are you?" Authorization answers "are you allowed to touch this record?" IDOR is what happens when the second check is missing.

Why vibe-coded apps get hit

AI builders scaffold routes fast: /api/users/:id, /projects/:id/settings, Supabase queries keyed by a path param. The happy path works on day one. The check that ties id to session.userId is easy to skip — or to write once on the list endpoint but forget on the detail endpoint.

It's not exotic. It's the gap between "logged in" and "owns this object," repeated across every resource type in your app.

How to check manually

1. Create two low-privilege test accounts (Alice and Bob).

2. As Alice, open dev tools → Network, use the app normally, and note every request with an ID in the path or query (/api/orders/…, ?userId=, etc.).

3. Replay those requests with Bob's ID while still using Alice's session. If Bob's data comes back, you have IDOR.

4. Try the same with no session at all — some endpoints leak to anonymous callers too.

How Blinkof scans for IDOR

Blinkof.ai runs a cross-tenant isolation test on apps you own:

• Front-door scan (free): probes guessable API routes from the outside and flags endpoints that return data without a login. That catches the worst cases but can't prove Alice-vs-Bob isolation.
• Deep scan (free after verification): signs in like a real user — via self-signup or a saved test login you provide.
• API discovery: on verified apps, Blinkof also reads your shipped JavaScript for discovered /api/* routes, checks sensitive routes anonymously, and feeds concrete ID-shaped API URLs into the cross-tenant test.
• Cross-tenant / IDOR pass: with two distinct accounts, Blinkof walks ID-addressed reads and tries to pull one customer's data while authenticated as the other. Strictly read-only; we clean up after ourselves.
• Web MCP metadata: if your app exposes MCP over HTTP/SSE, Blinkof checks whether tools/list is public. It does not call tools.

Add a second test login in your dashboard to arm the full check. Every finding includes a paste-ready fix prompt for Cursor, Claude Code, Lovable, or whatever you shipped with.

IDOR is the bug where your app treats "logged in" as "allowed." The fix is always the same: on every read and write, verify the session and that the authenticated user owns the object.

How to fix it

On every endpoint and server function that touches a user-owned record:

• Load the resource by ID and ownerId = session.userId (or equivalent tenant key).
• Return 404 or 403 when the row exists but doesn't belong to the caller — don't leak "exists but forbidden" vs "doesn't exist" if that matters for your threat model.
• For Supabase/Firebase: Row Level Security policies that bind rows to auth.uid(), not just "authenticated users can read."
• Never trust a client-supplied user ID when the server already knows who is signed in.