Por framework
Seguridad de Next.js — Server Actions, variables de entorno y CVE de dependencias
Los incidentes en Next.js ocurren en la frontera servidor/cliente: exposición de variables de entorno, falta de autorización en Server Actions y CVE de dependencias. Mantén los secretos en el servidor, delimita por propietario y monitorea los CVE. Sin pasos de ataque.
Para: cualquiera que opere una app con Next.js. Aquí no hay pasos de ataque — solo los incidentes que ocurren en la frontera servidor/cliente y cómo cerrarlos. Para el panorama completo, consulta el centro de seguridad por framework.
Los tres grandes escollos (en la frontera)
El escapado y el enrutamiento de Next.js son excelentes, pero estos tres son tuyos para cerrar cuidando la frontera.
① Exposición de variables de entorno
Mal uso de NEXT_PUBLIC_ o secretos pasados al cliente. Horneados en el bundle, visibles para los visitantes.
② Huecos de autorización en acciones
Sin comprobación de propietario en Server Actions / Route Handlers. Intercambia un ID y operas sobre datos de otro usuario.
③ CVE conocidos de dependencias
CVE del núcleo/dependencias (incl. RCE) sin parchear. Juzga por la versión en ejecución, parchea rápido.
Cómo cerrarlos (3 pasos)
Mantén los secretos en el servidor
NEXT_PUBLIC_ solo a valores seguros para el navegador; nunca a claves de API ni información de conexión. Lee los secretos solo dentro de componentes de servidor / Server Actions / Route Handlers, y mantenlos fuera de props y respuestas. (→ archivos .env y secretos)Autoriza en cada Server Action / Route Handler
Monitorea los CVE de dependencias con una máquina y parchea rápido
Habitual (peligroso)
- secretos con prefijo
NEXT_PUBLIC_, expuestos al cliente - Server Actions tratadas como «con sesión = permitido»
- obtener URL externas en el servidor sin protección (SSRF)
- CVE conocidos de dependencias sin parchear
Correcto
- los secretos son server-only, nunca se envían al cliente
- las acciones hacen autorización delimitada por propietario
- las peticiones de URL pasan por protección contra SSRF (bloquear IP internas, lista de permitidos)
- CVE de dependencias monitoreados con una máquina + parcheados rápido
La visión de este sitio: gestiona «la frontera y las dependencias», no el núcleo
Este sitio funciona sobre Next.js, y el centro de gravedad que de verdad protegemos no es una config vistosa sino la frontera servidor/cliente y la frescura de las dependencias. Los secretos se quedan en el servidor, los puntos de entrada públicos (Server Actions / Route Handlers) siempre llevan autorización, y las dependencias reciben una auditoría de CVE antes de cada despliegue. Nuestro propio origen fue un incidente de «CVE sin parchear explotado de forma automática», así que monitorear las dependencias con una máquina es un hábito de máxima prioridad. Todo código que obtiene una URL externa pasa por nuestra propia pasarela segura contra SSRF para que no pueda alcanzar IP internas ni metadatos (→ qué es SSRF).
Sigue leyendo
- Centro: seguridad por framework · seguridad de Laravel
- Dependencias: no quedarse atrás con los CVE · el manual de respuesta a vulnerabilidades
- Glosario: qué es IDOR · qué es SSRF · archivos .env y secretos
FAQ
Q¿Es Next.js un framework seguro?
Next.js tiene valores por defecto seguros (escapado de salida, etc.) y es bastante sólido de fábrica. Pero los incidentes no vienen de esos valores por defecto sino de cómo manejas la frontera servidor/cliente: secretos que debían ser server-only acabando en el cliente, olvidar la autorización en Server Actions y dejar sin parchear CVE conocidos de dependencias. No puedes confiar solo en los valores por defecto — la frontera y las dependencias las gestionas tú.
Q¿Cómo manejo las variables de entorno de forma segura?
La regla es «los secretos se quedan en el servidor». Solo antepón NEXT_PUBLIC_ a valores seguros para el navegador; nunca a claves de API ni información de conexión (los valores NEXT_PUBLIC_ se hornean en el bundle del cliente en tiempo de build y son visibles para los visitantes). Lee los secretos solo dentro de componentes de servidor / Server Actions / Route Handlers, y diseña de modo que nunca se cuelen en props ni en respuestas.
Q¿A qué debo prestar atención con las Server Actions?
Las Server Actions y los Route Handlers son puntos de entrada públicos del servidor. Que se puedan invocar no significa que esté permitido. Por encima del inicio de sesión (autenticación), escribe autorización que delimite cada operación al usuario que es propietario del objetivo. Olvídalo y alguien podrá actualizar o borrar datos de otro usuario con solo intercambiar un ID (autenticación ≠ autorización). Valida la entrada y haz siempre la comprobación de propiedad en la acción.