middleware.ts ya no existe: el cambio a proxy.ts en Next.js 16

Si actualizaste a Next.js 16 y tu middleware.ts sigue “funcionando” pero te tira un warning de deprecación en consola, no es un capricho de nomenclatura del equipo de Next.js. Hay una razón concreta detrás, y tiene que ver con seguridad real, no solo con claridad de nombres.

El cambio, en la práctica

// ❌ Antes: src/middleware.ts
export function middleware(request: NextRequest) {
  // ...
}

// ✅ Ahora: src/proxy.ts
export function proxy(request: NextRequest) {
  // ...
}

El archivo se renombra, la función exportada se renombra, y el config.matcher se mantiene igual. Pero hay un cambio de fondo más importante que el nombre: proxy.ts corre en el runtime de Node.js por defecto, no en el Edge Runtime limitado en el que corría middleware.ts tradicionalmente. Eso significa acceso a APIs de Node completas — incluyendo, por ejemplo, node:crypto para firmar tokens de sesión directamente ahí, algo que antes requería trucos con Web Crypto API.

Por qué el nombre importa: el CVE que lo motivó

En 2025 se reportó una vulnerabilidad (CVE-2025-29927) que afectaba versiones de Next.js entre la 11.1.4 y la 15.2.2: con un header HTTP específico, era posible saltarse por completo las validaciones de autorización que dependían solo del middleware. Si tu única capa de protección para rutas privadas era “el middleware verifica la cookie de sesión”, esa protección podía evadirse.

El rename a “proxy” no es solo estético — es una señal deliberada del equipo de Next.js: este archivo es infraestructura de ruteo, no debe ser tu único punto de control de seguridad. El nombre anterior, “middleware”, sugería (incorrectamente) una capa de seguridad robusta tipo firewall de aplicación. “Proxy” comunica mejor lo que realmente es: una capa de entrada que puede reescribir, redirigir o modificar requests — útil, pero no infalible como única defensa.

La implicación práctica: defensa en profundidad

Si tu código de autorización se ve así…

// proxy.ts — única capa de protección
export function proxy(request: NextRequest) {
  const token = request.cookies.get('session')?.value
  if (!isValidSessionToken(token) && request.nextUrl.pathname.startsWith('/admin')) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
  return NextResponse.next()
}

…y nada más valida la sesión en las rutas protegidas, tienes exactamente el patrón de riesgo que hizo posible el CVE mencionado: si por cualquier motivo (un bug futuro, una config de matcher mal armada, un edge case) esta capa se evita, no hay ninguna segunda barrera.

La solución es repetir la verificación en una capa independiente, más cerca del dato sensible:

// src/app/admin/(protected)/layout.tsx — segunda barrera, independiente del proxy
import { cookies } from 'next/headers'
import { redirect } from 'next/navigation'

export default async function ProtectedAdminLayout({ children }: { children: React.ReactNode }) {
  const token = (await cookies()).get('session')?.value

  if (!isValidSessionToken(token)) {
    redirect('/login')
  }

  return <>{children}</>
}

Sí, esto es “redundante” en el caso feliz donde el proxy funciona correctamente. Esa redundancia es exactamente el punto: una capa de seguridad nunca debería depender de que una sola verificación, en un solo lugar del código, sea perfecta para siempre.

No es exclusivo de Next.js

Este principio —defensa en profundidad— no es una particularidad de este framework. Cualquier sistema con una capa de “gateway” o “edge” que toma decisiones de autorización debería repetir esa validación más cerca del recurso protegido. La lección del CVE-2025-29927 es un recordatorio puntual de un principio general de seguridad que aplica en cualquier arquitectura con múltiples capas.

Migrando tu proyecto

Si tienes un middleware.ts existente, la migración es mecánica:

1. Renombra el archivo a proxy.ts.
2. Cambia export function middleware(...) a export function proxy(...).
3. El config.matcher se queda exactamente igual.
4. Revisa si tu lógica dependía de limitaciones del Edge Runtime (por ejemplo, evitabas ciertas librerías) — ahora, con runtime de Node.js completo, puede que ya no necesites esos workarounds.
5. Aprovecha el cambio para auditar: si tu proxy es la única capa de autorización de alguna ruta sensible, agrega una segunda verificación en el layout o Server Component correspondiente.

Conclusión

Este rename es uno de esos cambios donde vale la pena entender el “por qué” además del “cómo migrar”. No es solo una función que cambió de nombre — es una corrección de percepción sobre qué garantías realmente ofrece esta capa, motivada por una vulnerabilidad real que afectó proyectos en producción. Si tu autorización depende de una sola capa, este es un buen momento para revisarla.

¿Tu aplicación Next.js protege rutas sensibles con una sola capa de verificación? Agenda una auditoría de seguridad gratuita de 15 minutos.