IDOR: a logged-in user is not an authorized user

# Copy A's access token out of dev tools: Application > Local Storage,
# or the Authorization header on any request the app already makes.
export TOKEN_A="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
export BASE="https://your-app.com"
export B_RECORD_ID="7f3a1c04-9b55-4f0e-8a51-2d6c0b1e4a77"

curl -s -w '\nHTTP %{http_code}\n' \
  -H "Authorization: Bearer $TOKEN_A" \
  "$BASE/api/orders/$B_RECORD_ID"

A 404 or an empty result is correct. A 200 with B's data in it is an IDOR, confirmed, on that endpoint. Now repeat for PATCH and DELETE on the same record, because read-only IDOR and write IDOR are separate findings and the write one is worse.

for id in $(seq 1 50); do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    -H "Authorization: Bearer $TOKEN_A" \
    "$BASE/api/orders/$id")
  printf '%s %s\n' "$id" "$code"
done | awk '$2 == 200 { print }'

Count the 200s. If that number is larger than the number of orders user A actually placed, every extra one belongs to somebody else. This is the version of the test you can hand to a non-technical founder and have them understand the result immediately.

grep -rnE "findUnique|findFirst|findById|findOne|\.eq\('id'|where: *\{ *id" \
  --include="*.ts" --include="*.tsx" --include="*.js" \
  app/ pages/ src/ server/ api/ 2>/dev/null | grep -v node_modules

Then list the endpoints themselves, so you can see how many you are actually dealing with:

# Next.js App Router
find app -name "route.ts" -o -name "route.js" | sort

# Next.js Pages Router
find pages/api -name "*.ts" -o -name "*.js" | sort

# Express and friends
grep -rnE "app\.(get|post|put|patch|delete)\(|router\.(get|post|put|patch|delete)\(" \
  --include="*.ts" --include="*.js" src/ server/ | grep -v node_modules

Do not forget Next.js Server Actions. They are not in any route file listing, and they are public HTTP endpoints that anybody can invoke directly with whatever arguments they like. Every 'use server' function needs the same ownership check as a route handler:

grep -rn "'use server'" --include="*.ts" --include="*.tsx" app/ src/ | grep -v node_modules

import { NextRequest } from 'next/server';
import { auth } from '@/lib/auth';
import { prisma } from '@/lib/prisma';

export async function GET(req: NextRequest, { params }: { params: { id: string } }) {
  const session = await auth();
  if (!session) {
    return new Response('Unauthorized', { status: 401 });   // authentication: fine
  }

  // and that is the last time the current user is mentioned in this function
  const order = await prisma.order.findUnique({
    where: { id: params.id },
  });

  return Response.json(order);
}

Read the two halves separately. The top half asks "is there a valid session?" and answers it correctly. The bottom half asks "what is the order with this ID?" and answers that correctly too. Nothing in the function ever asks whether those two things have anything to do with each other. session.user.id is fetched and then never used.

There is a specific reason findUnique shows up here so reliably. Prisma's findUnique only accepts unique fields in its where, so you cannot add userId to it even if you want to. A model reaching for the most obvious "get one record" call lands on the one API that structurally cannot express the ownership filter, and then has no reason to reconsider.

-- vulnerable
select * from orders where id = $1;

app.get('/api/orders/:id', requireAuth, async (req, res) => {
  const { rows } = await db.query('select * from orders where id = $1', [req.params.id]);
  res.json(rows[0]);
});

// anyone with a valid session can change the status of anyone's order
await db.query('update orders set status = $2 where id = $1', [req.params.id, status]);

This is the shape behind the r/lovable report: "I could upgrade myself to premium, delete other users' data, or tamper with core records, all because PUT or PATCH endpoints were wide open." Reading someone else's data is a breach. Writing to it is a breach plus a data integrity problem you may never be able to unwind, because you will not know which rows were touched.

import { NextRequest } from 'next/server';
import { auth } from '@/lib/auth';
import { prisma } from '@/lib/prisma';

export async function GET(req: NextRequest, { params }: { params: { id: string } }) {
  const session = await auth();
  if (!session?.user?.id) {
    return new Response('Unauthorized', { status: 401 });
  }

  // findFirst, not findUnique, because the filter is no longer only the primary key
  const order = await prisma.order.findFirst({
    where: {
      id:     params.id,
      userId: session.user.id,   // the whole fix
    },
  });

  if (!order) {
    // 404, not 403: a 403 would confirm the record exists
    return new Response('Not found', { status: 404 });
  }

  return Response.json(order);
}

-- reads
select * from orders where id = $1 and user_id = $2;

// writes: filter in the statement, then confirm it actually applied
const { rowCount } = await db.query(
  'update orders set status = $2 where id = $1 and user_id = $3',
  [req.params.id, status, req.user.id]
);
if (rowCount === 0) return res.sendStatus(404);
res.sendStatus(204);

The rowCount === 0 check is not optional. Without it the update quietly affects zero rows, returns 200, and your UI cheerfully tells the attacker their change was saved, which hides the attempt from your logs and from you.

A per-endpoint fix that depends on remembering will eventually stop being remembered. Put the ownership filter in one place and route everything through it:

// lib/orders.ts
export function ordersFor(userId: string) {
  return {
    findOne: (id: string) =>
      prisma.order.findFirst({ where: { id, userId } }),
    list: () =>
      prisma.order.findMany({ where: { userId } }),
    update: (id: string, data: Prisma.OrderUpdateInput) =>
      prisma.order.updateMany({ where: { id, userId }, data }), // returns { count }
  };
}

Now the handler cannot express the unsafe query without deliberately going around the helper, and a reviewer grepping for prisma.order. outside lib/orders.ts has a complete list of the places to look. Note updateMany rather than update: Prisma's update has the same unique-field constraint as findUnique, so updateMany is what lets the ownership filter into the statement, and its count is what tells you whether it applied.

alter table public.orders enable row level security;
alter table public.orders force  row level security;

create policy "orders_select_own" on public.orders
  for select to authenticated
  using ( (select auth.uid()) = user_id );

create policy "orders_update_own" on public.orders
  for update to authenticated
  using      ( (select auth.uid()) = user_id )
  with check ( (select auth.uid()) = user_id );

Two caveats that decide whether this actually helps you.

• If your server connects with the Supabase service role key, RLS does nothing. That key carries the Postgres bypassrls attribute and ignores every policy. A route handler using it must do its own ownership check, exactly as in fix 01. This is the most common reason people write policies and remain vulnerable.
• If your frontend queries Supabase directly, a client-side filter is not a control. Writing .eq('user_id', user.id) in browser code is a convenience for you, not a constraint on an attacker, who can open dev tools and issue the request without it. The rule has to be the policy.

If you have not enabled row level security at all, that is a bigger and more urgent problem than IDOR on its own, and it is covered in full in the Supabase RLS article.

A 403 on a record that exists and a 404 on a record that does not is an oracle: an attacker can enumerate which IDs are real without ever seeing the data. Return 404 for anything the caller may not see, and return it identically whether the record is missing or merely not theirs.

The part people get wrong is consistency. If nineteen endpoints return 404 and one returns 403, the one is a free existence check for every ID in the system. Pick the behaviour once, put it in the shared helper, and do not let individual handlers improvise.

// vulnerable: the caller tells the server who they are
const orders = await prisma.order.findMany({
  where: { userId: req.nextUrl.searchParams.get('userId') },
});

// fixed: identity comes from the verified session, always
const orders = await prisma.order.findMany({
  where: { userId: session.user.id },
});

The rule: a user ID that arrives in a query string, a request body, a header or a hidden form field is an input, not an identity. The only identity is the one derived from a verified session or token.

// vulnerable: the body goes straight into the update
await prisma.user.update({ where: { id: session.user.id }, data: req.body });
// client posts {"name":"Dee","role":"admin","credits":999999}

// fixed: an explicit allowlist, nothing else can reach the database
const Body = z.object({ name: z.string().min(1).max(120) });
const parsed = Body.safeParse(await req.json());
if (!parsed.success) return new Response('Bad request', { status: 400 });
await prisma.user.update({ where: { id: session.user.id }, data: parsed.data });

Note that this one is an ownership check away from being invisible: the user is updating their own row, which every ownership rule permits. What they are not permitted to do is decide which columns. That distinction also has a database-level answer, revoke update (role, credits) on ... from authenticated, which is worth having as well.

// GET /api/projects/:projectId/tasks/:taskId
// vulnerable: the project is verified, the task is not bound to it
const project = await prisma.project.findFirst({
  where: { id: projectId, ownerId: session.user.id },
});
if (!project) return notFound();
const task = await prisma.task.findUnique({ where: { id: taskId } }); // any task at all

// fixed: the child is bound to the parent, and the parent to the user
const task = await prisma.task.findFirst({
  where: { id: taskId, project: { id: projectId, ownerId: session.user.id } },
});

This one is easy to miss in review because the handler visibly contains an authorization check. It is just checking the wrong object.

const RESOURCES = ['orders', 'invoices', 'documents', 'messages', 'uploads'];

describe.each(RESOURCES)('cross-user access on /api/%s', (resource) => {
  it('user A cannot read a record owned by user B', async () => {
    const res = await fetch(`${BASE}/api/${resource}/${seeded[resource].ownedByB}`, {
      headers: { Authorization: `Bearer ${tokenA}` },
    });
    expect(res.status).toBe(404);
  });

  it('user A cannot modify a record owned by user B', async () => {
    const res = await fetch(`${BASE}/api/${resource}/${seeded[resource].ownedByB}`, {
      method: 'PATCH',
      headers: { Authorization: `Bearer ${tokenA}`, 'Content-Type': 'application/json' },
      body: JSON.stringify({ title: 'tampered' }),
    });
    expect(res.status).toBe(404);
    // and assert the record is genuinely unchanged, not just that the status looked right
    const asB = await fetch(`${BASE}/api/${resource}/${seeded[resource].ownedByB}`, {
      headers: { Authorization: `Bearer ${tokenB}` },
    });
    expect((await asB.json()).title).not.toBe('tampered');
  });
});

The second assertion in the write test matters more than the status code. A handler can return 404 and still have performed the update, if the check and the write happen in the wrong order. Verify the object, not the response.

Add the resource name to the RESOURCES array every time you add an endpoint, and the test suite fails loudly the first time someone generates a handler without an ownership filter. That is worth more than any one-off audit, including ours.