Change the ID in the URL, Read Anyone's Data

The app had real auth. Login, sessions, protected routes — the whole thing. It felt locked down, and that feeling is exactly what made it dangerous. Because the endpoint that served your invoices checked that someone was logged in, and never once checked that the someone was you. Change one number in the URL and you were reading the next account’s data. Here’s the teardown, worst finding first.

This is a representative audit — the exact pattern I hit over and over on apps built with Cursor, Claude Code, Bolt, and v0. Names and paths are changed, but every finding is real-shaped and drawn from the kind of report the launchworthy skill produces. Call the app ledgerly: a Next.js + Prisma + Postgres billing dashboard, built in Cursor, pre-launch, days from onboarding its first paying teams.

It got a scorecard. The scorecard was blunt.

Zero domains passing does not mean ledgerly is a bad app. It’s a good app. It means it is finished-looking, which is the precise state in which people ship — and the auth was the kind that passes a glance and fails a probe.

The finding that ends the app: authentication without authorization

Here’s the route that served an invoice. It’s src/app/api/invoices/[id]/route.ts:11, and it looks completely reasonable:

// BROKEN: any logged-in user can read any invoice by guessing the id
export async function GET(req: Request, { params }: { params: { id: string } }) {
  const session = await getSession(req);
  if (!session) return new Response("Unauthorized", { status: 401 });

  const invoice = await prisma.invoice.findUnique({
    where: { id: params.id },   // ← no owner check
  });
  return Response.json(invoice);
}

Read it carefully, because the bug is what’s missing. There is an auth check — if (!session). That’s the trap. It confirms you’re logged in, and then it fetches the invoice by id alone. The query never asks whether this invoice belongs to the caller. So User A, fully authenticated, changes /api/invoices/inv_8841 to /api/invoices/inv_8842 and reads User B’s billing record. Sequential-ish Prisma ids make it a for loop, not a guess.

This is IDOR — Insecure Direct Object Reference — and it is the single most common critical I find in auth-heavy AI-built apps. The tool wired up login beautifully and then treated “logged in” as the finish line.

The fix is small, and it is the same idea in two places: ownership belongs in the query, and roles belong in the middleware.

export async function GET(req: Request, { params }: { params: { id: string } }) {
  const session = await getSession(req);
  if (!session) return new Response("Unauthorized", { status: 401 });

  const invoice = await prisma.invoice.findFirst({
    where: { id: params.id, userId: session.user.id },  // ownership in the query
  });
  if (!invoice) return new Response("Not found", { status: 404 });
  return Response.json(invoice);
}

Two principles do all the work here. Ownership goes in the where clause, not in an if after the fetch — filtering in the query means the database can never return a row you shouldn’t see. And the user id comes from the session on the server, never from a param the client controls, because if the client can send userId, an attacker sends someone else’s.

The false alarm: “you have to be logged in to hit it”

Now the credibility move — the objection the owner raised the instant I flagged the invoice route, and the reason a lot of “review my app” passes miss this bug entirely.

This is why generic code review skims past IDOR: the route has an auth check, so a reviewer pattern-matching on “is there a session guard?” sees green and moves on. The bug lives in the absence of a second check that no linter flags. You only catch it by asking the ownership question on every by-id fetch — which is exactly the manual probe launchworthy demands: log in as A, request B’s id, paste the response.

The rest of the punch list

The two criticals are the blockers — do not onboard a paying team until both are closed. The rest is ranked so the scope stays honest:

Three findings survive after the criticals. Note the shape: the two ownership bugs can leak every customer’s billing data, and the rest is homework. That ranking is the point — a flat list reads as equal chores; worst-first reads as “close these two doors before anyone signs up, then breathe.”

Why this keeps happening

None of this means Cursor built a bad app, or that ledgerly’s owner did anything foolish. AI builders are extraordinary at getting you to looks finished — and “there’s a login page” feels like security, which is precisely the trap. The tools wire up authentication cleanly because that’s the visible, demoable half. Authorization is the invisible half: it’s the check that isn’t there, the query constraint nobody sees missing, the admin route that renders fine on your own screen because you happen to be the admin.

That gap is the whole reason launchworthy exists. It plays bouncer at the door of production. It knows that authentication is not authorization, that an obscure URL is not a lock, that a public-by-design key is fine while a missing ownership check is fatal — and it hands you the constrained where clause, not just the finding.

The hard part was never the fix; it’s four added words in a query. The hard part is knowing that the app with real, working login was the one changed id away from handing every account to the next person who typed a different number.