Paste a route.
See who can call it.

Route handler with no session check

This GET/POST/PUT/PATCH/DELETE handler never calls auth() (or checks req.auth). Route handlers are public HTTP endpoints: anyone with curl can call them, signed in or not, no matter what your UI shows.

usually because

• –The agent built the UI behind a login and assumed the API behind it is private too
• –proxy.ts was supposed to protect it, but its matcher skips /api
• –The handler is wrapped in auth(), but req.auth is never checked

fix

1. 1.Call const session = await auth() at the top of every exported method
2. 2.Return 401 when !session?.user?.id, before reading params or the body
3. 3.Then check that the record belongs to session.user.id (see the ownership check)

+added: import { auth } from "@/auth";import { db } from "@/lib/db"; export async function GET() {−removed:   const projects = await db.project.findMany();+added:   const session = await auth();+added:   if (!session?.user?.id) {+added:     return Response.json({ error: "Unauthorized" }, { status: 401 });+added:   }+added:   const projects = await db.project.findMany({+added:     where: { userId: session.user.id },+added:   });  return Response.json(projects);}

Server Action with no session check

An exported Server Action never checks the session. Next.js docs: Server Actions are reachable via a direct POST request, not just through your UI, so hiding the button or the page does not protect the action.

usually because

• –The form that calls it is on a protected page, so the agent assumed the action is protected
• –Auth was checked in the page or layout, not inside the action
• –A matcher change or refactor moved the action out of proxy coverage

fix

1. 1.Call auth() inside every exported action, as the first line
2. 2.Throw or return an error when there is no session.user.id
3. 3.Validate the input on the server (e.g. zod) and scope the write to session.user.id

"use server";+added: import { auth } from "@/auth";import { db } from "@/lib/db";import { revalidatePath } from "next/cache"; export async function deleteProject(id: string) {−removed:   await db.project.delete({ where: { id } });+added:   const session = await auth();+added:   if (!session?.user?.id) throw new Error("Unauthorized");+added:   // deleteMany + userId: deletes nothing if the project isn't theirs+added:   await db.project.deleteMany({ where: { id, userId: session.user.id } });  revalidatePath("/dashboard");}

Record loaded by id with no ownership check

The query looks a record up by id alone. Being signed in is authentication; being allowed to touch THIS record is authorization. Any signed-in user can change the id in the URL or request and read, edit or delete someone else's data (an IDOR).

usually because

• –findUnique({ where: { id } }) is the shortest query that works in the demo
• –The id comes from params, the body or a form and is trusted as-is
• –The agent checked auth() and stopped there

fix

1. 1.Put the owner into the query: findFirst({ where: { id, userId: session.user.id } })
2. 2.For writes use updateMany / deleteMany with the same where, and check count
3. 3.Return 404 (not 403) when nothing matches, so ids can't be probed

export async function GET(_req: Request, { params }: { params: Promise<{ id: string }> }) {  const session = await auth();  if (!session?.user?.id) return Response.json({ error: "Unauthorized" }, { status: 401 });  const { id } = await params;−removed:   const invoice = await db.invoice.findUnique({ where: { id } });+added:   const invoice = await db.invoice.findFirst({ where: { id, userId: session.user.id } });+added:   if (!invoice) return Response.json({ error: "Not found" }, { status: 404 });  return Response.json(invoice);}

Trusting userId, role or plan from the request

The code reads who the user is (userId, ownerId, role, isAdmin, plan) from the body, form data or query string. That is attacker-controlled: anyone can send userId of another account or role: "admin".

usually because

• –The client already knows the user id, so the agent posts it along
• –A role or plan flag was added to the form to make the UI work
• –zod validates the shape of userId but not whose it is

fix

1. 1.Take the user id only from the session: session.user.id
2. 2.Read role and plan from your database on the server, never from the request
3. 3.Remove the field from the client payload and the zod schema

export async function POST(req: Request) {−removed:   const { userId, title } = await req.json();−removed:   const note = await db.note.create({ data: { userId, title } });+added:   const session = await auth();+added:   if (!session?.user?.id) return Response.json({ error: "Unauthorized" }, { status: 401 });+added:   const { title } = await req.json(); // validate with zod+added:   const note = await db.note.create({ data: { userId: session.user.id, title } });  return Response.json(note);}

401 response created but not returned

The session check builds a 401 response but doesn't return it, so execution continues and the handler runs for signed-out users anyway.

usually because

• –NextResponse.json(...) inside the if without return
• –A refactor turned a one-line return into a block

fix

1. 1.Write return NextResponse.json(..., { status: 401 })
2. 2.redirect() from next/navigation throws by itself and needs no return

const session = await auth();if (!session?.user?.id) {−removed:   NextResponse.json({ error: "Unauthorized" }, { status: 401 });+added:   return NextResponse.json({ error: "Unauthorized" }, { status: 401 });}

Auth only in a client component (UI hiding)

This client component decides access with useSession() or a session prop and hides or redirects in the browser. That's fine for UX, but it protects nothing: the JavaScript, the API routes and the Server Actions it calls are all still reachable directly.

usually because

• –The agent used useSession() and router.push("/login") like a SPA
• –Pro or admin buttons are hidden instead of the action being blocked
• –Next.js docs call return-null-if-unauthorized in a top-level component 'not recommended'

fix

1. 1.Keep the UI hiding, but check auth() on the server for the page (redirect) and in every route/action it calls
2. 2.Prefer a server page: const session = await auth(); if (!session?.user?.id) redirect("/login")
3. 3.Gate Pro features with the plan read from the DB, server-side

−removed: "use client";−removed: import { useSession } from "next-auth/react";+added: import { redirect } from "next/navigation";+added: import { auth } from "@/auth";+added: import { AdminPanel } from "./admin-panel"; // the "use client" part −removed: export default function Admin() {−removed:   const { data: session } = useSession();−removed:   if (!session) return null;−removed:   return <DeleteAllUsersButton />;+added: export default async function AdminPage() {+added:   const session = await auth();+added:   if (!session?.user?.id) redirect("/login");+added:   // + check the role from the DB, and again inside every admin action+added:   return <AdminPanel />;}

Server page reads data with no session check

This Server Component queries the database (or a private API) without calling auth(). If the page is meant to be private, anyone can open it. If it relies on the layout or proxy to block access, see those checks: neither is a complete guard.

usually because

• –The auth check lives in the layout only
• –The agent assumed proxy.ts covers this path
• –The page started public and grew private data

fix

1. 1.Call auth() in the page (or a shared data-access helper it uses) and redirect when signed out
2. 2.Scope the query to session.user.id
3. 3.With cacheComponents on, keep request-time reads (auth(), DB) inside <Suspense> or mark the page dynamic

+added: import { redirect } from "next/navigation";+added: import { auth } from "@/auth";+added: import { db } from "@/lib/db";+added:  export default async function Billing() {−removed:   const invoices = await db.invoice.findMany();+added:   const session = await auth();+added:   if (!session?.user?.id) redirect("/login?callbackUrl=/billing");+added:   const invoices = await db.invoice.findMany({ where: { userId: session.user.id } });  return <InvoiceList invoices={invoices} />;}

Auth check only in a layout

Next.js docs: layouts don't re-render on client navigation, so the session isn't re-checked on every route change, and a layout doesn't stop nested pages or Server Actions from running. A redirect in layout.tsx is a nice first gate, not the guard.

usually because

• –One check in app/dashboard/layout.tsx looks like it covers every child page
• –SPA habit: return null from a top-level component when signed out

fix

1. 1.Keep the layout check if you like, but repeat auth() in each page, route and action (or in one data-access helper they all call)
2. 2.In the layout, fetch user data for the nav; do the auth check close to the data

−removed: export default async function DashboardLayout({ children }: { children: React.ReactNode }) {+added: import "server-only";+added: import { cache } from "react";+added: import { redirect } from "next/navigation";+added: import { auth } from "@/auth";+added:  +added: /** Call from every private page, action and route, not just the layout. */+added: export const requireUserId = cache(async () => {  const session = await auth();−removed:   if (!session) redirect("/login");−removed:   return <Shell>{children}</Shell>;−removed: }+added:   if (!session?.user?.id) redirect("/login");+added:   return session.user.id;+added: });

Admin code checks sign-in but not the role

This looks like admin code, and it checks that someone is signed in, but never checks a role or permission. Every signed-in user is then an admin.

usually because

• –auth() was copied from a user route and the role check never added
• –The role check exists only in the client (hidden admin link)

fix

1. 1.Read the role from the database (or a session field you set server-side in the Auth.js callbacks)
2. 2.Return 403 / notFound() when the user isn't an admin, in every admin route and action

export async function DELETE(req: Request) {  const session = await auth();  if (!session?.user?.id) return Response.json({ error: "Unauthorized" }, { status: 401 });+added:   const me = await db.user.findUnique({ where: { id: session.user.id }, select: { role: true } });+added:   if (me?.role !== "ADMIN") return Response.json({ error: "Forbidden" }, { status: 403 });  await db.user.deleteMany({ where: { banned: true } });  return Response.json({ ok: true });}

Proxy matcher leaves routes uncovered

The matcher skips paths you may think are protected: a negative lookahead that excludes api, a '/dashboard' entry without ':path*' (so /dashboard/settings isn't matched), or a non-literal matcher (Next.js ignores dynamic values). Server Actions are POSTs to the page they're used on, so excluding a path also skips its actions.

usually because

• –The Auth.js example matcher excludes api
• –'/dashboard' was written instead of '/dashboard/:path*'
• –The matcher was built from a variable or array spread

fix

1. 1.Use literal matcher strings with :path* for every protected section
2. 2.Treat proxy as an optimistic redirect only: Next.js docs say it should not be your only line of defense
3. 3.Check auth() inside every route handler and Server Action as well

export const config = {−removed:   matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)", "/dashboard"],+added:   // literal strings only; :path* covers nested pages (and their Server Actions)+added:   matcher: ["/dashboard/:path*", "/settings/:path*", "/api/projects/:path*"],};+added: // Still check auth() inside every route handler and Server Action.

Auth.js proxy that never blocks anyone

export { auth as proxy } only redirects signed-out users if auth.ts defines callbacks.authorized; without it, Auth.js treats every request as authorized and the proxy just keeps sessions alive. Wrapping your own function in auth() adds req.auth, but you still have to check it.

usually because

• –The Auth.js snippet was pasted without the authorized callback
• –auth((req) => NextResponse.next()) reads nothing from req.auth

fix

1. 1.Check req.auth in your wrapped proxy and redirect when it's empty
2. 2.Or add callbacks.authorized in auth.ts that returns !!auth?.user
3. 3.Proxy runs on the Node.js runtime in Next.js 16; keep it to optimistic checks

−removed: export { auth as proxy } from "@/auth";+added: import { NextResponse } from "next/server";+added: import { auth } from "@/auth";+added:  +added: export default auth((req) => {+added:   if (!req.auth?.user) {+added:     const url = new URL("/login", req.nextUrl.origin);+added:     url.searchParams.set("callbackUrl", req.nextUrl.pathname);+added:     return NextResponse.redirect(url);+added:   }+added: });+added:  +added: export const config = { matcher: ["/dashboard/:path*", "/settings/:path*"] };

middleware.ts / middleware export in Next.js 16

Next.js 16 deprecated the middleware file and export name in favor of proxy (proxy.ts, export function proxy). Deprecated middleware still runs, but auth code copied from older Auth.js docs often still says auth as middleware.

usually because

• –Code or docs written for Next.js 15 and earlier
• –The agent followed an older Auth.js snippet

fix

1. 1.Run npx @next/codemod@latest middleware-to-proxy . or rename the file to proxy.ts and the export to proxy
2. 2.proxy always uses the Node.js runtime; if you need edge, the docs say keep middleware for now

−removed: // middleware.ts−removed: export { auth as middleware } from "@/auth";+added: export { auth as proxy } from "@/auth";+added: // needs callbacks.authorized in auth.ts to actually block (see above)