Guías de seguridad
Ejecutar Next.js de forma segura: no quedarse atrás con los CVE publicados
Con Next.js, lo más temible es dejar sin parchear un CVE publicado — un RCE CVSS 10.0 de hace meses ha causado brechas reales. Cuatro pilares: juzgar por la versión en ejecución, monitorear las dependencias con una máquina, actualizar rápido, y mínimo privilegio — a través de la lente operativa de este sitio.
Para: cualquiera que despliegue apps con Next.js (o frameworks JS similares), especialmente «lo construí con ayuda de IA, operando a ojo». Destilado de un incidente real (→ el CVSS 10.0 descuidado).
La visión de este sitio: la batalla no se gana con la «velocidad»
Los desarrolladores indie normalmente pierden en seguridad no por falta de conocimiento sino por falta de continuidad operativa. Leer las noticias de CVE más rápido que nadie no tiene valor (deja la velocidad a los proveedores y a las noticias). Lo que funciona es un sistema que no se perderá los CVE relevantes para ti. Así que este artículo se apoya en «sistematizar», no en «saber más».
1. Juzga por la versión en ejecución
Mide «¿estoy en una versión peligrosa?» por lo que está realmente en ejecución, no por el piso del manifiesto — porque el número del manifiesto y la versión en ejecución a menudo discrepan.
✗ Contar por el piso de package.json
"next": "^16.0.0" → «16.0.0 es vulnerable, así que nosotros también» — sobrecontado como «8 vulnerables».
✓ Contar por la versión en ejecución
npm ls next muestra la versión resuelta → las autoincrementadas están a salvo, solo las fijadas se quedan atrás. Realmente 2.
# ve las versiones realmente resueltas
npm ls next react react-dom
# dentro de un contenedor en ejecución
docker exec <container> npm ls nextLos rangos con caret (^16.0.0) se autoincrementan al reconstruir; las dependencias fijadas se quedan atrás. Los números de aquí son la verdad.
2. Monitorea tus dependencias con una máquina
Rastrear CVE a mano es imposible, y el fallo se convierte en el incidente. Deja que las máquinas vigilen.
Monitoreo gratuito de dependencias
osv-scanner scan -L pnpm-lock.yamlEn GitHub, activa Dependabot (Settings → Security). Recibirás PRs solo para los CVE que coincidan con tus dependencias.
Lo que importa es la priorización. La postura de este sitio: clasifica por «¿está siendo explotado (KEV)?» por «¿qué tan alto es el CVSS?». Un CVSS alto que no usas es de bajo impacto; una puntuación media bajo explotación activa es máxima prioridad — esa priorización es el trabajo real.
3. Disciplina de actualización: corrige la raíz, no el síntoma
Cuando aparece una vulnerabilidad, actualiza el framework a la versión parcheada para cerrar el agujero en sí.
Ocultar el síntoma (insuficiente)
- Bloquear solo las peticiones «de aspecto sospechoso» en un proxy inverso
- Detener los cargos/el síntoma y llamarlo «resuelto»
- Dejar el RCE en sí vivo
Corrección de raíz (correcta)
- Actualizar el framework a la versión parcheada
- Tras actualizar, confirmar que la firma desaparece en tus registros
- Tratar los primeros auxilios y la corrección de raíz como dos trabajos distintos, haz ambos
El fallo común
«Detuve los cargos/el síntoma» ≠ «resuelto». Los primeros auxilios y cerrar la vulnerabilidad son trabajos distintos. Haz ambos.
4. Mínimo privilegio para reducir el radio de impacto
Contén el daño si te golpean.
Ejecuta como usuario sin privilegios
USER del contenedor como root. Una brecha solo alcanza «ese privilegio».Vincula BD/Redis solo a la red interna
Separa por servicio
Estas deciden si una brecha se detiene en «robo de entorno dentro de un contenedor» o llega a «toma de control del host».
Esto lo hacemos nosotros mismos
Este sitio monitorea sus propias dependencias en busca de CVE, exactamente como se escribe aquí — para que el incidente que lo empezó todo (un CVSS 10.0 público descuidado) nunca vuelva a pasarse por alto un humano. Decimos «clasifica por prioridad (KEV + CVSS)» porque así operamos de verdad.
Leer a continuación
- Incidente: un RCE público descuidado facturado de forma fraudulenta
- Glosario: CVE · CVSS · RCE
- Historia: Log4Shell — RCE a través de una dependencia
FAQ
Q¿Qué importa más para la seguridad de Next.js?
Antes que no escribir bugs, es no dejar sin parchear los CVE publicados del framework o de sus dependencias. La mayoría de las brechas graves vienen de agujeros conocidos descuidados, no de ataques novedosos.
Q¿Puedo saber si soy vulnerable a partir de package.json?
No. El `^` (piso) en package.json no refleja la realidad — los rangos con caret se autoincrementan al reconstruir, las dependencias fijadas se quedan atrás. Juzga siempre por la versión realmente en ejecución.
Q¿Cuál es la primera cosa que hacer, en solitario?
Activa Dependabot (GitHub) u osv-scanner para que las máquinas vigilen tus dependencias en busca de CVE. Las patrullas manuales siempre fallan. Un sistema que continúa supera a más conocimiento.