Middleware has critical limitations including: it cannot perform slow data fetching due to edge latency constraints, it's vulnerable to header-based bypass attacks, it has been replaced by 'proxy.ts' in Next.js 16, and only a single root middleware file is allowed
Next.js Middleware is powerful for routing logic but comes with significant limitations that affect its use for authentication, data fetching, and security enforcement. These limitations stem from its edge runtime environment, architectural constraints, and recent security vulnerabilities that have reshaped how middleware should be used in production applications.
No slow data fetching: Middleware cannot perform slow fetch calls because it runs at the edge and must be fast. Any fetch to a non-globally-distributed backend adds unacceptable latency . The Vercel Conformance rule
NO_FETCH_FROM_MIDDLEWAREflags any fetch calls from middleware for review .Single root middleware only: Unlike during beta, you cannot have nested middleware files. Only one root
middleware.tsfile is allowed, and you must use conditional logic to handle different paths .Edge runtime constraints: Middleware runs in a limited edge environment with restricted Node.js APIs and execution time limits. Long-running operations are not permitted .
No static file serving: Middleware does not run for static files served from
_next/staticorpublicdirectory by default, which must be explicitly excluded via matcher config .
Two major vulnerabilities have exposed fundamental security limitations of middleware. CVE-2024-51479 allowed bypassing middleware by adding a __nextLocale query parameter, which caused URL path normalization issues and let attackers access protected routes . More critically, CVE-2025-29927 (CVSS 9.1) allowed complete middleware bypass by crafting the x-middleware-subrequest header with predictable values like middleware:middleware:middleware:middleware:middleware . This affects all self-hosted Next.js applications using next start with output: 'standalone' prior to patched versions . The vulnerability demonstrates that middleware cannot be trusted as the sole line of defense for authentication and authorization.
Based on these limitations, middleware cannot safely handle: authentication as the primary mechanism (must be supplemented with route-level checks), slow data fetching from centralized backends, complex session management that requires database access, or any operation that needs more than a few milliseconds of execution time. The official guidance states that middleware is not a good fit for session management and authorization checks, despite many applications using it this way .
In Next.js 16, middleware.ts is now deprecated and renamed to proxy.ts. The function export must be renamed from middleware to proxy. Additionally, proxy.ts only runs on the Node.js runtime and no longer supports the Edge Runtime . This architectural shift reflects the changing role of request preprocessing in the framework.