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 el mantenimiento continuo.
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 ── Mantenimiento continuo
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)
Son funciones del lado servidor que cualquiera puede llamar. 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 donde suele producirse el 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: céntrate en la frontera servidor/cliente y en las dependencias
Este sitio funciona con Next.js, y lo prioritario no es una configuración especial, sino la frontera servidor/cliente y mantener las dependencias al día. Los secretos se quedan en el servidor, las funciones que cualquiera puede llamar (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. Este sitio nació tras un incidente en el que un CVE sin parchear se explotó de forma automática, 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
Fuentes y alcance
Estas fuentes primarias respaldan los ajustes, el alcance o las medidas anteriores; enlaces comprobados el 23 de octubre de 2026. Revisa sus condiciones de versión y configuración. Las prioridades y lecciones son recomendaciones del sitio, no una revalidación completa ni una garantía de seguridad.