Por framework
Seguridad de Express (Node.js) — las defensas que añades tú mismo
Express casi no protege nada por defecto, así que las defensas las añades tú: cabeceras de seguridad, validación de entrada, autorización (no solo autenticación), limitación de tasa y CVE de dependencias (npm). Defensivo, sin pasos de ataque.
Para: cualquiera que ejecute una API o app en Express (Node.js). Aquí no hay pasos de ataque, solo las defensas que añades a un framework mínimo. Para el panorama completo, consulta el centro de seguridad por framework.
Las defensas que añades (lo que no está en los valores por defecto)
Express aporta solo la base de enrutamiento y middleware. Lo siguiente no existe salvo que lo añadas.
Cabeceras de seguridad
CSP/HSTS/X-Content-Type, etc. Añádelas con middleware estilo helmet.
Validación de entrada
La entrada sin validar es la puerta para SQLi/XSS/inyección.
Autorización (ámbito del propietario)
Quedarte en la autenticación y un cambio de ID revela datos de otros (IDOR).
Limitación de tasa
Frena la fuerza bruta en el login, el abuso de la API y el DoS.
CVE de dependencias (npm)
Monitorea de forma automática y parchea los fallos conocidos de las muchas dependencias.
Secretos y SSRF
Secretos en variables de entorno, no en el código / protección SSRF para las peticiones salientes.
Cómo cerrarlas (los cinco mínimos)
Añade cabeceras de seguridad
Valida y sanea toda la entrada
Escribe autorización, no solo autenticación
Limitación de tasa y monitoreo de CVE de dependencias
Común (peligroso)
- respuestas en bruto sin cabeceras
- entrada pasada a BD/HTML sin validar
- sin autorización — "con sesión = permitido"
- sin límites de tasa, CVE de dependencias sin parchear
Correcto
- cabeceras establecidas con middleware estilo helmet
- entrada validada y saneada
- autorización acotada al propietario
- límites de tasa + monitoreo de CVE de dependencias + parcheo rápido
La visión de este sitio: un framework mínimo empareja libertad con responsabilidad
El atractivo de Express es su ligereza y libertad, lo que significa que también diseñas tú la defensa. Este sitio corre sobre otra pila, pero lo esencial para Node es idéntico: establece cabeceras, valida la entrada, escribe siempre autorización en los puntos de entrada públicos y audita las dependencias en busca de CVE antes de cada despliegue. Node tiene especialmente 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: esa es la manera correcta de usar Express.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Next.js (también Node)
- Práctica: monitorear los CVE de dependencias · Herramienta: comprobación de cabeceras de seguridad
- Glosario: qué es IDOR · qué es SSRF
FAQ
Q¿Express es un framework seguro?
Express es 'minimalista' por diseño: aporta la base de enrutamiento y middleware y apenas incluye funciones de seguridad. Así que no es ni seguro ni peligroso; las defensas las añades tú. A diferencia de Rails o Laravel, que protegen mucho por defecto, aquí tienes que cablear tú mismo las cabeceras, la validación de entrada, la autorización y la limitación de tasa. Más libertad, más responsabilidad.
Q¿Necesito cabeceras de seguridad como las de helmet?
Sí. Express no establece cabeceras HTTP de seguridad por defecto. Usa middleware estilo helmet para añadir CSP, HSTS, X-Content-Type-Options, etc., y así reducir riesgos básicos como el clickjacking y el MIME sniffing. Es una mejora de base con solo añadirlo, por eso vale la pena ponerlo primero.
Q¿Cuál es el mínimo imprescindible?
(1) Añade cabeceras de seguridad (estilo helmet); (2) valida y sanea toda la entrada; (3) no te quedes en el login (autenticación): escribe una autorización acotada al propietario; (4) limita la tasa en login y APIs; (5) monitorea de forma automática los CVE de dependencias (npm) y parchea rápido. Estos cinco cubren la mayoría de los huecos de un framework mínimo.