Por framework
Seguridad de Express (Node.js) — una referencia de hardening para producción
Una referencia de hardening para producción en Express (Node.js): al ser minimalista, tú añades las defensas — cabeceras helmet, CVE de npm, validación de entrada, autorización, limitación de tasa, sesiones/CSRF y SSRF. Defensiva, sin pasos de ataque.
Para: cualquiera que opere una API o app con Express (Node.js). Aquí no hay pasos de ataque — esta es una referencia práctica de las defensas que añades a un framework mínimo: una lista de comprobació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 comprobación de hardening ordenada por prioridad
Realiza esta tabla de arriba abajo. P0 es un requisito previo, P1 es la fuente más frecuente de incidentes, P2 es higiene operativa continua.
P0 ── Requisito previo (hazlo primero)
Cabeceras (helmet) + desactivar x-powered-by / monitoreo de CVE de dependencias npm / secretos desde env, sin exponer la pila
P1 ── Principal fuente de incidentes
Validación de entrada y defensa contra inyección / autorización acotada al propietario
P2 ── Higiene operativa
Limitación de tasa y topes de tamaño / sesiones, cookies, CSRF / SSRF
| Prioridad | Control | Detalles (Express) |
|---|---|---|
| P0 | Cabeceras de seguridad | estilo helmet: CSP/HSTS/X-Content-Type, etc. Desactiva x-powered-by |
| P0 | CVE de dependencias npm | Monitorea con npm audit/osv-scanner; juzga por la versión en ejecución, parchea rápido |
| P0 | Secretos y errores | Secretos desde variables de entorno. No expongas stack traces en producción |
| P1 | Validación de entrada | Valida/sanea las entradas (tipo/rango/valores permitidos). Topes de tamaño de cuerpo |
| P1 | Inyección | Vincula las consultas a la BD. Vigila la inyección de operador NoSQL ($). No pases la entrada a eval |
| P1 | Autorización | Autenticación + autorización acotada al propietario en cada ruta. JWT: verifica la firma, fija el alg |
| P2 | Limitación de tasa | Límites de intentos/caudal en el login/las APIs. Frena la fuerza bruta, el abuso, el DoS |
| P2 | Sesiones/cookies | secure/httpOnly/sameSite. CSRF (sesiones en cookie). Almacén de sesión de producción |
| P2 | SSRF | Lista de permitidos para las peticiones del lado del servidor + bloqueo de IP internas/metadatos |
1. Cabeceras de seguridad y reducción de la exposición (P0)
Express no establece cabeceras de seguridad por defecto. Mejora esta base primero.
- Usa middleware estilo helmet para añadir CSP, HSTS, X-Content-Type-Options, frameguard, etc.
- Desactiva
x-powered-bypara reducir la exposición del framework/versión. - Comprueba tu propio sitio con el verificador de cabeceras de seguridad.
2. Dependencias (npm) y cadena de suministro (P0)
- Monitorea con una máquina los CVE de dependencias con
npm auditu osv-scanner, juzga por la versión en ejecución y parchea rápido (→ monitorear los CVE de dependencias). - Node tiene un árbol de dependencias grande y riesgo de cadena de suministro (typosquatting, hooks
postinstall). Escruta en el momento de instalar y mantén el número bajo. - Mantén Node en una versión soportada (LTS) y no dejes versiones EOL en su sitio.
3. Validación de entrada e inyección (P1)
- Valida/sanea toda la entrada (body, query, params, cabeceras). Establece un tope de tamaño de cuerpo para frenar el DoS.
- SQL: vincula con marcadores de posición; nunca construyas consultas por concatenación de cadenas (→ qué es la inyección SQL).
- NoSQL: vigila la inyección de operador (
$) mediante entrada de tipo objeto (no pases objetos crudos a las consultas). - No pases entrada externa a evaluaciones peligrosas como
eval.
4. Autenticación y autorización (P1)
Habitual (peligroso)
- sin autorización — «con sesión = permitido»
- dependencia solo del orden/presencia de los middleware
- confiar tal cual en los ID/flags suministrados por el cliente
- firma de JWT sin verificar /
alg:nonepermitido
Correcto
- autenticación más autorización acotada al propietario en cada ruta
- verifica cerca de los datos (no dependas del orden)
- vuelve a verificar en el servidor (resiste el intercambio de ID)
- verificación de firma de JWT + alg fijado (rechaza
alg:none)
Consulta qué es IDOR · qué es JWT. Puedes inspeccionar el contenido de un JWT tú mismo (decodificador de JWT).
5. Limitación de tasa y abuso (P2)
- Aplica límites de intentos/caudal a login, APIs y restablecimiento de contraseña para frenar la fuerza bruta, el abuso y el DoS.
- Establece topes de tamaño en los cuerpos de las peticiones y las subidas (evita el agotamiento por cargas grandes).
6. Sesiones y cookies (P2)
- Establece
secure/httpOnly/sameSiteen las cookies de sesión. - Para apps con sesión en cookie, añade protección CSRF (→ qué es CSRF).
- Usa un almacén de sesión adecuado en producción (el almacén en memoria por defecto no es para producción). Regenera la sesión al iniciar sesión.
7. SSRF y peticiones del lado del servidor (P2)
- Las peticiones del lado del servidor a URL suministradas por el usuario deben restringir los destinos a una lista de permitidos y bloquear el alcance a IP internas / metadatos de la nube en el momento de conectar (→ qué es SSRF).
8. Manejo de errores y configuración de producción (P0–P2)
- Usa un manejador de errores central y no expongas stack traces externamente.
- Ejecuta con
NODE_ENV=production. Tras un proxy, configuratrust proxycorrectamente para que el esquema y la IP de cliente no se malinterpreten. - Termina TLS/HTTPS de forma fiable.
Verifica: ¿está tu Express realmente endurecido?
Construirlo no es el final — solo está hecho una vez que lo has comprobado. Estas son autoverificaciones defensivas contra tu propio entorno.
Cabeceras y exposición
x-powered-by ha desaparecido, mediante el verificador de cabeceras.Los errores no filtran información interna
La autorización se sostiene
Dependencias, limitación de tasa, SSRF
npm audit/osv está limpio, que la limitación de tasa del login funciona y que las peticiones salientes no pueden alcanzar IP internas.La visión de este sitio: un framework mínimo une libertad con responsabilidad
El atractivo de Express es su ligereza y libertad — lo que significa que tú diseñas también la defensa. Lo que Rails y Laravel protegen por defecto (cabeceras, CSRF, un andamiaje de autorización), en Express lo cableas de forma deliberada. El centro de gravedad es trabajar la tabla de arriba de arriba abajo — establece cabeceras, valida la entrada, escribe autorización en los puntos de entrada públicos y monitorea las dependencias en busca de CVE. Node especialmente tiene un gran número de dependencias, así que la frescura de las dependencias decide los incidentes. Abandona la suposición de que «el framework lo protegerá» y añade las defensas de forma explícita.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Next.js (también Node)
- Práctica: monitorear los CVE de dependencias · el manual de respuesta a vulnerabilidades
- Glosario: qué es IDOR · qué es SSRF · qué es JWT · qué es CSRF
- Herramientas: verificador de cabeceras de seguridad · decodificador de JWT
FAQ
Q¿Qué debo hacer primero para asegurar Express?
Los tres puntos P0: (1) añade cabeceras de seguridad (CSP/HSTS, etc.) con middleware estilo helmet y desactiva x-powered-by; (2) monitorea con una máquina los CVE de dependencias npm y parchea rápido, juzgando por la versión en ejecución; (3) lee los secretos del entorno y no expongas stack traces en producción. Express no protegerá esto por ti por defecto, así que añadirlo es la base. Luego, avanza hacia la validación de entrada, la autorización y la limitación de tasa.
Q¿Necesito cabeceras de seguridad como helmet?
Sí. Express no establece cabeceras HTTP relacionadas con la seguridad por defecto. Usa middleware estilo helmet para añadir CSP, HSTS, X-Content-Type-Options, etc., reduciendo riesgos básicos como el clickjacking y el MIME sniffing. Desactiva también x-powered-by para reducir la exposición del framework. Es una mejora de base con solo añadirlo, así que ponlo primero.
Q¿Cómo configuro la autenticación y la autorización?
Después de que un middleware de autenticación confirme el inicio de sesión, escribe siempre una autorización acotada al propietario en cada ruta — que el objetivo pertenezca de verdad al usuario. No dependas del orden de los middleware ni de su mera presencia; verifica cerca de los datos. Si usas JWT, exige la verificación de firma y fija el alg (rechaza alg:none).
Q¿Cómo gestiono las vulnerabilidades de dependencias npm?
Monitorea con una máquina los CVE conocidos con npm audit u osv-scanner y parchea rápido, juzgando por la versión en ejecución. Node tiene un árbol de dependencias muy grande y riesgo de cadena de suministro (typosquatting, hooks postinstall), así que la frescura de las dependencias y el escrutinio en el momento de instalar marcan la diferencia. Mantén también Node en una versión soportada (LTS).
Q¿Cuál es el mínimo imprescindible?
(1) cabeceras estilo helmet + desactivar x-powered-by, (2) validar/sanear toda la entrada, (3) autorización acotada al propietario, (4) límites de tasa + topes de tamaño de cuerpo en el login/las APIs, (5) monitoreo de CVE de dependencias npm + parcheo rápido, (6) no exponer stack traces en producción. Este conjunto mínimo cubre la mayoría de los huecos de un framework mínimo.