Middleware is not your auth layer (a Next.js footgun I keep finding)

When I audit Next.js apps built quickly (often with AI tools), one pattern shows up more than any other: routes are protected in middleware.ts, and the API route handlers trust that.

// app/api/admin/users/route.ts
export async function GET(request: NextRequest) {
  // "middleware already checked"
  const users = await db.user.findMany()
  return NextResponse.json(users)
}

Middleware can be skipped by a matcher that doesn't cover a new route, misconfigured during a refactor, or bypassed by calling the API directly. If the handler doesn't check, the data is open.

The fix is boring: every handler that touches user data verifies the session and role itself.

export async function GET(request: NextRequest) {
  const session = await getServerSession(authOptions)
  if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  if (session.user.role !== 'admin') return NextResponse.json({ error: 'Forbidden' }, { status: 403 })

  const users = await db.user.findMany()
  return NextResponse.json(users)
}

Two related checks worth doing while you're there:

• Hiding the admin dashboard in React when role !== 'admin' is UI gating, not access control. The API behind it still needs the server-side check.
• Delete a user's session row and make a request with their old cookie. If it still works, revocation isn't wired up.

Rule of thumb: middleware is a convenience layer for redirects and early exits. The security boundary is the handler.

How do you handle this in your apps: a shared requireUser() helper, or checks inline in each route?