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 mantenimiento continuo.
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 ── Mantenimiento continuo
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. Añádelas 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 que las cargas grandes agoten la memoria y otros recursos).
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: con un framework mínimo, las defensas las diseñas tú
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, soporte de autorización integrado), en Express lo cableas de forma deliberada. Lo prioritario es recorrer la tabla de arriba desde el principio: establece cabeceras, valida la entrada, escribe autorización en los endpoints públicos y monitorea las dependencias en busca de CVE. Node en especial tiene un gran número de dependencias, así que mantenerlas al día decide en buena medida si ocurren 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
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.