Auth boundaries: why middleware and layouts cannot protect, and the Data Access Layer that can

Middleware is a doorman, not a vault

Ask yourself: if someone could skip your auth check entirely — not attack it, just skip it — how much would be exposed? That question is not hypothetical; CVE-2025-29927 answered it for every app whose only check was in middleware.

Middleware runs before route resolution, on every matched request, which makes it feel like the natural place for auth — one file, all routes covered. But look at what it can actually do well: it executes in a constrained runtime where you should not be doing database lookups on every request, so the practical pattern is an optimistic check — read the session cookie, maybe verify a signature locally, and redirect unauthenticated users to /login before any rendering work happens. That is genuinely valuable: it is fast (sub-millisecond, no IO), it keeps logged-out users from ever seeing a flash of protected UI, and it centralizes the redirect policy. What it must never be is the only check.

CVE-2025-29927 is the canonical proof, and its mechanism is worth knowing precisely. Next.js used the x-middleware-subrequest header internally to prevent infinite recursion — if middleware triggered a fetch that re-entered middleware, the header told Next “already done, skip.” The trust boundary failure: external requests carrying that header were indistinguishable from internal ones, so an attacker who knew the expected value (derivable from the middleware file path, repeated to satisfy the recursion-depth check) could instruct the framework to skip your auth entirely. Vercel’s hosted platform stripped the header at the edge; self-hosted deployments were exposed. The patch fixed the header, but the class survives: any single front-door check can be bypassed by header smuggling, proxy misrouting, a matcher pattern that forgot a route, or the next CVE. Defense-in-depth is not a compliance phrase here — it is the design conclusion the incident forces.

Layouts do not protect their children

The second tempting place for auth is layout.tsx — it wraps every page below it, so a session check there looks like a perimeter. It is not, for two architectural reasons that have nothing to do with bugs. First, layouts do not re-render on client-side navigation: partial rendering preserves shared layouts, so navigating from /dashboard/a to /dashboard/b re-renders only the page segment. Your layout’s auth check ran once, on the first load — if the session was revoked since, or the user logged out in another tab, navigation within the section never re-asks the question. Second, layouts and pages render independently. They are separate entries in the RSC payload, rendered in parallel server passes; a layout cannot pass props to its page, and crucially, the page’s data fetches do not wait for the layout’s auth check to pass. The protected data is being fetched while the layout is still deciding whether to redirect.

There is a sharper version of the same fact: a client can request the RSC payload for a specific segment directly. Partial prerendering and per-segment requests mean the framework’s unit of delivery is the segment, not the wrapped tree — so reasoning “my page is safe because something above it checks” assumes a nesting guarantee the rendering model does not give you. A redirect() in a layout is a UX courtesy that usually fires; it is not a security boundary that always fires. The Next.js authentication docs say this in one line — do auth checks close to the data source, not in layouts — and teams skim past it because the layout check appears to work in every manual test. It fails exactly in the cases nobody manually tests: revoked sessions mid-navigation, direct segment fetches, races between parallel renders.

The Data Access Layer: check at every read

When you see a codebase where auth checks are scattered across layouts, pages, and middleware, the question is not “is each check correct?” but “can a request reach a query without hitting any of them?” The answer is almost always yes — and the DAL eliminates that class of question by making the check inseparable from the read.

The boundary that survives all of the above is the one attached to the data itself. A Data Access Layer (DAL) is a module — the only module — through which queries for protected data flow, and every function in it starts by verifying the session. No path to the data can skip the check, because the check is the path. React’s cache() makes this affordable: verifySession is memoized per request, so ten DAL calls in one render tree cost one session lookup, not ten.

// app/lib/dal.ts
import 'server-only';
import { cache } from 'react';
import { cookies } from 'next/headers';
import { redirect, notFound } from 'next/navigation';
import { kv } from '~/lib/kv';
import { db } from '~/lib/db';

export const verifySession = cache(async () => {
  const token = (await cookies()).get('__Host-session')?.value;
  const session = token ? await kv.get(`session:${token}`) : null;
  if (!session) redirect('/login');   // memoized: 10 calls per render = 1 lookup
  return session;
});

export async function getInvoice(id: string) {
  const session = await verifySession();        // runs on EVERY read — this is the boundary
  const invoice = await db.invoice.findUnique({ where: { id } });
  if (invoice?.ownerId !== session.userId) notFound(); // instance-level authz, not just authn
  return { id: invoice.id, total: invoice.total };     // DTO: return fields, not rows
}

Notice the second check: ownerId !== session.userId. Authentication (“who are you”) at the top of the function, authorization (“may you see this row”) before the return — both belong in the DAL because both are properties of the data access, not of the route. The DTO return is part of the same discipline: return the fields the UI needs, never the raw row, so a future client component receiving this object cannot leak columns nobody meant to ship. The layered result: middleware gives fast optimistic redirects (UX), pages and layouts render whatever they like (presentation), and the DAL is the single place where a security claim is actually enforced — the place a middleware bypass, a forgotten matcher entry, or a layout race cannot reach, because the request still has to come through verifySession to touch a row.