Back to Common risks

Common risksLogin and accounts

Change the number in the URL, read someone else's record

Being logged in is not the same as being allowed. If your API returns any user's record when a stranger changes the ID in the URL, you have an IDOR bug (Insecure Direct Object Reference): the reference to the object is guessable and unchecked.

What can go wrong

A typical AI-generated pattern looks like this: /api/users/123 returns user 123's profile with no check that the caller is user 123 (or an admin).

Sequential IDs (1, 2, 3) are easy to scrape. UUIDs are harder to guess but still vulnerable if there is no authorization check: anyone who obtains one ID can try others, or share a link that leaks data.

The frontend may hide the "view other users" button. The API endpoint still answers if you curl it or change the fetch URL.

It happened for real

Researchers found a Lovable-built education app where changing the user ID in API calls exposed roughly 18,000 student records across six critical findings (VibeWrench audit, 2026). The pattern is common: VibeWrench reported similar BOLA/IDOR issues in about 21% of audited vibe-coded apps.

How to check yours

Seatbelt flags this automatically (partial). We soft-flag /api/users/:id-shaped routes and handlers that load a record by client-supplied ID without an obvious session or ownership check. We also flag Prisma findUnique by id without an owner scope in auth-protected routes.

Honest holes: export/download routes and sequential-ID heuristics are not flagged automatically yet. A soft flag means "read this handler yourself."

Ask your agent: "List every API route that takes a user or record ID from the URL or request body. For each one, show where we verify the caller owns that record or has admin role."

We don't catch this yet: Authorization enforced only in middleware that our static read cannot see, or IDOR reachable only through GraphQL field selection.

Fix direction

Every read and write by ID must check the session: where: { id, userId: session.user.id } or equivalent. Return the same generic 404 or 403 for missing and forbidden rows so attackers cannot enumerate accounts.

Paste into your agent: "Audit all routes with :id parameters. Add ownership checks before any database read or write. Use generic error messages for wrong user and missing record."

Related risks