Por framework
Seguridad de Next.js — una referencia de endurecimiento para producción
Referencia de endurecimiento de Next.js en producción: lista de verificación por prioridad, la frontera servidor/cliente y variables de entorno, CVE de dependencias, autorización en Server Actions, SSRF y CSP. Sin pasos de ataque.
Para: cualquiera que gestione una aplicación Next.js (se asume App Router). Aquí no hay pasos de ataque — esta es una referencia de trabajo para el endurecimiento: una lista de verificación ordenada por prioridad, guía por área y autoverificación. Para el panorama entre frameworks, consulta el centro de seguridad por framework.
Lista de verificación de endurecimiento ordenada por prioridad
Haz esta tabla de arriba hacia abajo. P0 es un requisito previo, P1 es la fuente más frecuente de incidentes, P2 es la higiene operativa continua.
P0 ── Requisito previo (haz esto primero)
Secretos solo en el servidor / monitorización de CVE de dependencias + parcheo rápido / configuración de producción firme
P1 ── Principal fuente de incidentes
Autorización + validación de entrada en Server Actions/Route Handlers / SSRF en las peticiones del servidor
P2 ── Higiene operativa
Cabeceras/CSP / autenticación, sesión, cookies / limitación de tasa
| Prioridad | Control | Detalles (Next.js) |
|---|---|---|
| P0 | Secretos solo en el servidor | NEXT_PUBLIC_ solo para valores seguros para el navegador; los secretos solo en Server Component/Action/Route Handler |
| P0 | CVE de dependencias | Monitoriza con npm audit/osv-scanner; juzga por la versión en ejecución, parchea rápido. Mantente al día con el RCE del núcleo |
| P0 | Configuración de producción | Ejecuta una compilación de producción; no filtres detalles internos (pila/entorno) en los errores |
| P1 | Autorización de acciones | Autenticación + autorización delimitada al propietario en cada Server Action/Route Handler |
| P1 | Validación de entrada | Valida la entrada por esquema (tipo/rango/permitido). No confíes en el cliente |
| P1 | Protección contra SSRF | Restringe las peticiones de URL del lado servidor a una lista de permitidos + bloquea IP internas/metadatos. Limita los patrones remotos de imágenes |
| P2 | Cabeceras/CSP | Cabeceras de seguridad + HSTS en next.config. Considera una CSP basada en nonce en App Router |
| P2 | Autenticación/cookies | Cookies de sesión Secure/HttpOnly/SameSite. No dejes la autorización solo al middleware |
| P2 | Limitación de tasa | Límites en la autenticación, las Server Actions y los Route Handlers |
1. La frontera servidor/cliente y las variables de entorno (P0)
La mayor fuente de incidentes de Next.js son los secretos que debían ser solo del servidor y acaban en el cliente.
- Solo antepón
NEXT_PUBLIC_a valores seguros para el navegador. Nunca a claves de API ni a información de conexión (los valoresNEXT_PUBLIC_se incrustan en el paquete del cliente en tiempo de compilación y son visibles para los visitantes). - Lee los secretos solo dentro de los Server Components / Server Actions / Route Handlers, y mantenlos fuera de las
propsy las respuestas (valores serializados). - Mantén los módulos solo de servidor fuera del alcance de importación del cliente (una inclusión accidental puede empaquetar secretos). Consulta los archivos .env y los secretos.
2. CVE de dependencias y el núcleo (P0)
- Monitoriza con una máquina los CVE de dependencias (npm) con
npm auditu osv-scanner, juzga por la versión en ejecución y parchea rápido (decide según lo que está realmente instalado, no según la declaración de package.json). - El núcleo de Next.js ha tenido RCE graves, así que mantente al día rápidamente cuando se publique uno. Para la disciplina operativa consulta no quedarse atrás con los CVE; para la práctica, el manual de respuesta a vulnerabilidades.
- Mantén Node/Next en versiones soportadas y no dejes versiones en fin de vida (EOL) en su lugar.
3. Server Actions / Route Handlers (autorización + validación, P1)
Estos son puntos de entrada públicos del servidor. Que se puedan llamar no significa que esté permitido.
Común (peligroso)
- acciones tratadas como "con sesión iniciada = permitido"
- confiar solo en la autenticación del middleware, sin comprobación de propiedad
- entrada pasada a la BD o a llamadas externas sin validar
- confiar tal cual en valores suministrados por el cliente (IDs, flags)
Correcto
- autenticación más autorización delimitada al propietario/permiso en cada acción/handler
- no lo dejes al middleware (autoriza cerca de los datos)
- valida por esquema la entrada (tipo/rango/permitido)
- vuelve a verificar en el servidor para que el intercambio de IDs no funcione
Consulta qué es IDOR. Haz una comprobación de propiedad en cada ruta de lectura/actualización/eliminación.
4. SSRF y peticiones del lado servidor (P1)
La obtención del lado servidor de URL suministradas por el usuario (proxies de imágenes, webhooks, obtención de metadatos) es una entrada de SSRF.
- Restringe los destinos a una lista de permitidos, y en el momento de la conexión bloquea el acceso a IP privadas y a los metadatos de la nube (169.254.169.254).
- Mantén los patrones remotos de optimización de imágenes al mínimo (no permitas obtener hosts arbitrarios).
- Consulta qué es SSRF. Este sitio enruta las peticiones salientes a través de una pasarela segura contra SSRF.
5. Inyección y salida
- XSS: React escapa la salida por defecto. No pases la entrada del usuario a
dangerouslySetInnerHTML(solo tras sanitizar si realmente es necesario). Consulta qué es XSS. - SQL/inyección: vincula con un ORM/marcadores de posición; nunca construyas consultas por concatenación de cadenas (→ qué es la inyección SQL).
- No pases entrada externa a evaluaciones peligrosas como
eval.
6. Cabeceras de seguridad y CSP (P2)
- Configura cabeceras de seguridad (X-Content-Type-Options, etc.) y HSTS en
next.config. Comprueba tu propio sitio con el verificador de cabeceras de seguridad. - En App Router, considera una CSP basada en nonce (evita permitir scripts en línea de forma generalizada). Ten en cuenta que coexistir con etiquetas de analítica/anuncios requiere diseño.
7. Autenticación, sesión, cookies (P2)
- Configura Secure / HttpOnly / SameSite en las cookies de sesión.
- No delegues la autorización solo a la autenticación del middleware — el middleware es un complemento; verifica la decisión real en la capa de acción/handler/datos (algunas rutas pueden eludir el middleware).
- Regenera y expira las sesiones apropiadamente al iniciar sesión.
8. Limitación de tasa (P2)
- Aplica límites de intentos/rendimiento a la autenticación, las Server Actions y los Route Handlers para frenar la fuerza bruta, el abuso y el DoS.
Verifica: ¿está tu Next.js realmente endurecido?
Construirlo no es el final — está hecho solo una vez que lo has comprobado. Estas son autoverificaciones defensivas contra tu propio sitio/entorno.
No se filtran secretos al cliente
NEXT_PUBLIC_ a un secreto.Producción no filtra detalles internos en los errores
La autorización de acciones se mantiene
Cabeceras, dependencias, SSRF
npm audit/osv está limpio, y que las peticiones salientes no pueden acceder a IP internas.La visión de este sitio: gestiona 'la frontera y las dependencias', no el núcleo
Este sitio funciona con Next.js, y el centro de gravedad no es una configuración vistosa, sino la frontera servidor/cliente y la actualidad de las dependencias. Los secretos se quedan en el servidor, los puntos de entrada públicos (Server Actions/Route Handlers) llevan siempre autorización y validación de entrada, y las dependencias reciben una auditoría de CVE antes de cada despliegue. Nuestro propio origen fue un incidente de "CVE sin parchear explotado automáticamente", así que monitorizar las dependencias con una máquina es un hábito de máxima prioridad. Las peticiones salientes de URL pasan por una pasarela segura contra SSRF para que no puedan acceder a IP internas ni a metadatos.
Lecturas siguientes
- 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 · los archivos .env y los secretos · XSS
- Herramientas: verificador de cabeceras de seguridad
FAQ
Q¿Qué debo hacer primero para asegurar Next.js?
Los tres elementos P0: (1) mantén los secretos solo en el servidor (solo antepón NEXT_PUBLIC_ a valores seguros para el navegador, nunca a claves de API ni a información de conexión); (2) monitoriza los CVE de dependencias con una máquina, juzga por la versión en ejecución y parchea rápido (incluido el RCE del núcleo); (3) refuerza la configuración de producción (ejecuta una compilación de producción; no filtres detalles internos en los errores). Después, pasa a la autorización y la validación de entrada en Server Actions / Route Handlers, y a la protección contra SSRF.
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 a información de conexión (los valores NEXT_PUBLIC_ se incrustan en el paquete del cliente en tiempo de compilación y son visibles para los visitantes). Lee los secretos solo dentro de los componentes de servidor / Server Actions / Route Handlers, y diseña de modo que nunca se cuelen en las props ni en las respuestas.
Q¿Qué debo vigilar con las Server Actions?
Las Server Actions y los Route Handlers son puntos de entrada públicos del servidor. Que se puedan llamar no significa que esté permitido. Además del inicio de sesión (autenticación), escribe autorización que delimite cada operación a su propietario, y valida siempre la entrada (p. ej. validación por esquema). No confíes solo en la autenticación del middleware — haz también la comprobación de propiedad en la acción/handler.
Q¿Cómo me preparo para SSRF?
La entrada principal es la obtención del lado servidor de URL suministradas por el usuario (proxies de imágenes, webhooks, obtención de metadatos). Restringe los destinos a una lista de permitidos y, en el momento de la conexión, bloquea el acceso a IP privadas y a los metadatos de la nube (169.254.169.254). Mantén los patrones remotos de optimización de imágenes al mínimo. Consulta el glosario para más detalle.
Q¿Cómo gestiono las vulnerabilidades de las dependencias de npm?
Monitoriza con una máquina los CVE conocidos con npm audit u osv-scanner, juzga por la versión en ejecución y parchea rápido (decide según lo que está realmente instalado, no según la declaración de package.json). El núcleo de Next.js ha tenido RCE graves, así que mantenerse al día rápidamente importa. Además, mantén Node/Next en versiones soportadas y no dejes versiones en fin de vida (EOL) en su lugar.