Public-accessible subnetworks separated from internal networks

CMMC 2.0 SC.L1-3.13.5 (NIST 800-171r2 3.13.5) requires separation between publicly accessible subnetworks and internal networks. In application terms, this means public-facing routes and protected internal routes must be architecturally separated — not mixed under the same middleware or path structure with inconsistent access controls. OWASP A01 and CWE-284 (Improper Access Control) describe the failure mode: when admin and public endpoints share the same routing layer with no access boundary, a path traversal or misconfigured matcher exposes privileged functionality to public access.

Use Next.js route groups to create a hard architectural boundary between public, protected, and admin routes. Apply middleware targeting each group explicitly rather than relying on path string matching alone:

src/app/
├── (public)/            # No auth — landing, login, about
├── (protected)/         # Auth required — dashboard, documents
└── (admin)/             # Auth + admin role required

// middleware.ts
export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl
  const session = request.cookies.get('session')

  if (pathname.startsWith('/dashboard') || pathname.startsWith('/documents')) {
    if (!session) return NextResponse.redirect(new URL('/login', request.url))
  }

  if (pathname.startsWith('/admin') || pathname.startsWith('/api/admin')) {
    if (!session) return NextResponse.redirect(new URL('/login', request.url))
    // Each admin handler must also verify role server-side
  }
  return NextResponse.next()
}

Verify the middleware matcher pattern does not exclude /api/* paths — that is the most common source of bypass gaps in Next.js applications.