Seguridad de Next.js: el tema no se limita a “actualizar el framework”. Antes de una puesta en producción, hay que verificar la versión exacta, el uso del middleware, el alojamiento elegido, las cabeceras HTTP y las dependencias de React. Desde 2024, varias vulnerabilidades de Next.js han afectado a la autenticación, la caché, los Server Components y el self-hosting. Para un directivo, la cuestión es sencilla: evitar que una elección técnica acelere el proyecto hoy pero aumente fortemente el riesgo mañana.
Seguridad de Next.js: lo que realmente cambia para un proyecto web
Next.js es un Marco JavaScript basado en React, utilizado para crear sitios rápidos, plataformas SaaS, áreas de clientes o sitios editoriales con renderizado del lado del servidor. El renderizado del lado del servidor significa que una parte de la página la prepara el servidor antes de llegar al navegador. Esto es excelente para el rendimoriento y el SEO, pero también crea puntos de entrada adicionales.
El riesgo no es teorrico. En marzo de 2025, se publicó la vulnerabilidad CVE-2025-29927 con una puortuación CVSS de 9.1, por tanto crítica. Permitía eludir ciertos controles de autorización mediante una cabecera interna, x-middleware-subrequest, en versiones de Next.js anteriores a 12.3.5, 13.5.9, 14.2.25 y 15.2.3.
Para una pyme, la posible consecuencia es muy concreta: un espacio normalmente protegido, por ejemplo un back-office, una extranet o una página de validación de pedido, puede pasar a ser accesible si la arquitectura se apoya mal en el middleware. El middleware es una capa de procesamiento que se ejecuta antes de la página, a menudo utilizada para filtrar los accesos.
Este punto merece una decisión desde la fase de definición. Next.js puede ser una muy buena opción para un proyecto ambicioso, pero solo si el equipo prevé un presupuesto de mantenimiento. Con ese presupuesto, a veces es mejor una base más sencilla, bien mantenida, que una arquitectura moderna pero dejada sin seguimiento tras la entrega.
Las vulnerabilidades recientes que conviene conocer antes de desplegar
Las vulnerabilidades publicadas por Vercel, GitHub, el NVD o el equipo de React muestran un patrón claro: las zonas sensibles son la autenticación, la caché, los Server Components, las reescrituras de URL y ciertas configuraciones self-hosted. Los Server Components son componentes de React que se ejecutan del lado del servidor para reducir el JavaScript enviado al navegador.
Aquí tienes las referencias útiles para hablar con un proveedor, sin entrar en el detalle del código:
| Vulnerabilidad o aviso | Año | Riesgo principal | Versiones o correctivos conocidos |
|---|---|---|---|
| CVE-2025-29927 | 2025 | Elusión de autorización mediante middleware | Correctivos: 12.3.5, 13.5.9, 14.2.25, 15.2.3 |
| GHSA-gp8f-8m3g-qvj9 | 2024 | Cache poisoning, puortuación CVSS 7.5 | Afecta a >=13.5.1 <14.2.10, correctifs 13.5.7 y 14.2.10 |
| CVE-2025-55182 / CVE-2025-66478 | 2025 | Ejecución remota de código relacionada con los React Server Components | React CVSS 10.0, Next.js 15.x y 16.x deben actualizarse inmediatamente |
| CVE-2025-55183 | 2025 | Exposición de código fuente a través de Server Actions | Correctifs en 16.0.9, 15.5.8, 15.4.9, 15.3.7, 15.2.7, 15.1.10, 15.0.6 |
| GHSA-c4j6-fc7j-m34r | 2026 | SSRF en self-hosting con servidor Node.js integrado y WebSocket upgrades | Correctifs 15.5.16 y 16.2.5, despliegues de Vercel indicados como no afectados |
El cache poisoning consiste en hacer que la caché almacene una respuesta errónea y luego servirla a otros visitantes. Es discreto, a veces difícil de diagnosticar, y especialmente molesto en un sitio con fort tráfico. Las vulnerabilidades SSRF, por su parte, permiten a un atacante hacer que el servidor llame a recursos internos o externos no previstos.
En los proyectos que llevamos a cabo, vemos a menudo una confusión entre “el sitio funciona” y “el sitio está listo para producción”. Son dos estados distintos. La producción supone un nivel adicional de control: registro, actualizaciones, copias de seguridad, pruebas de seguridad y plan de reversión.
Vercel, OVH, servidor dedicado: el alojamiento cambia el nivel de riesgo
Next.js está historicamente muy asociado a Vercel, la plataforma creada por el editor del framework. No es algo trivial. Varios avisos de seguridad precisan que algunos despliegues de Vercel no están afectados por vulnerabilidades que afectan al self-hosting, especialmente casos relacionados con las rewrites, la caché o los WebSocket upgrades.
El self-hosting es el alojamiento en su propia infraestructura o con un proveedor como OVHcloud, Scaleway, AWS, Google Cloud o un servidor gestionado por un proveedor de servicios informáticos. Puede ser pertinente por razones de coste, soberanía, conformité o integración de negocio. Pero transfiere más responsabilidad técnica al equipo que opera el sitio.
La trampa que los no técnicos ignorent: “Next.js funciona sobre Node.js” no significa que todas las funcionalidades se comporten igual en todas partes. Los CDN (redes de distribución), los proxies, las rewrites, las funciones de servidor y los adapters pueden modificar el comportamiento real. Next.js 16.2, anunciado en 2026 con un trabajo sobre las plataformas y adapters, va precisamente en ese sentido: el contexto de despliegue importa.
Si compara las opciones, integre también la elección del runtime JavaScript, es decir, el entorno que ejecuta el código del servidor. Para entender las diferencias entre Node.js, Bun y Deno, esta guía sobre la elección de un runtime JavaScript en 2026 completa útilmente la reflexión.
Checklist de seguridad antes de la puesta en producción
Una revisión de seguridad de Next.js no necesita ser interminable para ser útil. Sobre todo, debe ser sistemática. El objetivo es detectar los errores costosos antes de que el sitio se exponga públicamente.
- Verificar la versión exacta de Next.js, React y React DOM, y luego compararla con los avisos de GitHub/Vercel publicados.
- Comprobar que el middleware no porta por sí solo la autorización de acceso a las zonas sensibles.
- Filtrar las cabeceras entrantes peligrosas a nivel de CDN o reverse proxy, en particular las cabeceras internas.
- Configurar una CSP, Content Security Policy, que limite los scripts autorizados para reducir los riesgos de XSS.
- Probar la caché: páginas privadas nunca almacenadas en caché, páginas públicas correctamente invalidadas.
- Prever un proceso de actualización con entorno de preproducción y copia de seguridad.
- Supervisar los logs y las alertas de errores después de cada despliegue.
La CSP merece una atención particular. La documentación oficial de Next.js indica que sirve para reducir los riesgos de XSS, clickjacking e inyección de código. También recomienda Next.js v13.4.20 o una versión más reciente para una buena gestión de los nonces, esos tokens temporarios que autorizan ciertos scripts de manera controlada.
Atención aun así: una CSP mal diseñada da una falsa impresión de seguridad. Si autoriza demasiados dominios, o si se inyectan datos no fiables en scripts beforeInteractive, pierde gran parte de su utilidad. En mayo de 2026, avisos de Vercel/GitHub enumeraron precisamente cuestiones de XSS relacionadas con el App Router, los nonces CSP y los scripts tempranos.
Presupuesto y plazos: lo que hay que prever honestamente
En el mercado francés, una revisión de seguridad ligera antes de la puesta en línea de un sitio Next.js cuesta a menudo entre 1 500 y 4 000 € sin IVA, según el alcance. Suele cubrir versiones, configuración, cabeceras HTTP, rutas sensibles, dependencias y recomendaciones de corrección. Para una aplicación de negocio con autenticación, pagos o datos personales, una auditoría más exhaustiva puede superar los 6 000 a 12 000 € sin IVA.
Los plazos son razonables si el tema se anticipa. Cuente entre dos y cinco días laborables para una revisión específica, y luego algunos días adicionales para corregir correctamente. Si la auditoría llega la víspera del lanzamiento, el coste rara vez aumenta en la factura inicial, pero se dispara en las decisiones: reporte de campaña, estrés de los equipos, correcciones rápidas y deuda técnica.
Sinceramente, esta tecnología solo se justifica si acepta su ritmo de mantenimiento. Next.js evoluciona rápido. Es una force para el rendormiento, el SEO y laexperiencia del usuario, pero eso impone una vigilancia regular, sobre todo con el App Router, las Server Actions y los Server Components.
A veces, un sitio escaparate sencillo puede estar mejor servido por WordPress bien securizado, un generador estático o una arquitectura más clásica. En cambio, para un área de cliente, un producto SaaS o un sitio editorial conectado a un CMS headless, Next.js sigue siendo muy pertinente si la seguridad está prevista en el presupuesto de funcionamiento.
Los errores frecuentes que salen caros después del lanzamiento
El primer error consiste en poner la autenticación “en el bord” del sitio, y luego suponer que todo está protegido. El middleware puede filtrar, pero las comprobaciones de acceso también deben existir del lado del servidor, lo más cerca posible de los datos. De lo contrario, una vulnerabilidad de bypass se vuelve mucho más grave.
Otro error: confundir actualización menor y riesgo menor. Las correctifs de seguridad llegan a veces en versiones que parecen banales. Reporter una subida de versión durante seis meses puede dejar el sitio expuesto a ataques documentados, por tanto más fáciles de reproducir.
La elección de los proveedores también cuenta. Un equipo capaz de entregar una interfaz cuidada no siempre tiene experiencia en explotación, supervisión y correctifs de urgencia. Si duda entre recursos internos, freelance y agencia, este punto sobre la organización del desarrollo para una pequeña empresa ayuda a establecer los criterios adecuados.
Por último, la seguridad debe estar vinculada al ciclo del proyecto. Los errores clásicos de definición, validación o responsabilidades mal definidas también debilitan la parte técnica. Los riesgos enumerados en los errores que hay que evitar lors de la creación de un sitio web se encuentran a menudo en los proyectos Next.js, con un impacto más fort lorsque la aplicación manipula datos de clientes.
Del lado de la agencia, el reflejo es tratar la seguridad como un lote de producción, no como una opción al final del proyecto. Definir este tipo de despliegue de antemano evita la mayoría de las malas sorpresas: versión objetivo, alojamiento, responsabilidades de mantenimiento, presupuesto de correction y plan de emergencia en caso de aviso crítico.
Preguntas frecuentes sobre la seguridad de Next.js
¿Es Next.js seguro para un sitio profesional?
Sí, Next.js puede ser seguro para un sitio profesional, siempre que se mantenga y configure correctamente. El riesgo proviene sobre todo de las versiones sin parchear, del self-hosting mal gestionado y de los controles de acceso demasiado centralizados en el middleware.
¿Qué versión de Next.js hay que utilizar en producción?
Hay que utilizar una versión supportée y corrigée según los últimos avisos de Vercel/GitHub. En la práctica, verifique siempre la rama exacta del proyecto, porque los correctifs publicados en 2025 y 2026 varían según Next.js 13, 14, 15 o 16.
¿Es Vercel más seguro que un alojamiento de OVH o AWS?
Vercel reduce algunos riesgos específicos de Next.js, ya que la plataforma está diseñada para este framework y algunas opiniones indican despliegues de Vercel no afectados. OVHcloud, AWS o Scaleway siguen siendo posibles, pero requieren un mayor dominio de Node.js, CDN, proxy, logs y actualizaciones.
¿Cuánto cuesta una auditoría de seguridad de Next.js?
Para una revisión específica antes del lanzamiento, prevea a menudo alrededor de 1 500 a 4 000 € HT en Francia. Una aplicación con cuentas de usuario, datos personales o pago suele requerir un presupuesto más elevado.