Next.js 15 Parallel Routes: The Authorization Gaps You Probably Have

Parallel routes in Next.js 15 let you render multiple pages simultaneously — @dashboard, @sidebar, @notifications. Each is a separate route tree, each runs its own server components.

Each also needs its own authorization check.

The trap

The canonical tutorial shows auth inside @dashboard/page.tsx:

export default async function Dashboard() {
  const session = await auth();
  if (!session) redirect("/sign-in");
  return <DashboardContent userId={session.userId} />;
}

If @sidebar/page.tsx doesn't check auth, an attacker can navigate directly to a crafted URL that renders only @sidebar — and that route still fetches user data. The redirect in the other slot doesn't stop it.

Fix

Every parallel slot that fetches data is its own authorization boundary:

// @sidebar/page.tsx
export default async function Sidebar() {
  const session = await auth();
  if (!session) return null;  // render empty, don't leak
  return <Nav userId={session.userId} />;
}

For a belt-and-suspenders approach, move auth into a layout that wraps every slot:

// app/(protected)/layout.tsx
export default async function ProtectedLayout({ children, dashboard, sidebar }) {
  const session = await auth();
  if (!session) redirect("/sign-in");
  return <>{dashboard}{sidebar}</>;
}

VibeWShield's IDOR scanner

Our auth_check scanner enumerates routes and replays each one with and without session cookies. When a parallel slot serves different data for two different users (anonymous vs session A), it's flagged as broken authorization.