Escena Viva ya tiene routers, controladores y middleware propio. Si la desplegaras hoy funcionaría, y también funcionaría cualquiera que quisiera hacerle daño: no envía cabeceras de seguridad, no controla desde qué origen la llaman, no registra las peticiones en un formato estándar, no comprime nada y no impide que un script compre las 1189 entradas libres del catálogo en un bucle de diez segundos. En esta lección montamos el kit mínimo: cinco paquetes, uno más mencionado, y para cada uno la misma tríada —qué problema resuelve, cómo se configura y qué pasa si no lo pones—, todos pasados antes por el filtro de auditoría del módulo 5.

1. El criterio del módulo 5 aplicado a cada paquete
2. helmet: cabeceras de seguridad
3. cors: peticiones desde otro origen
4. morgan: registro HTTP
5. compression: ancho de banda
6. express-rate-limit: límites de uso
7. cookie-parser: preparando el módulo 8
8. El orden correcto: crearAplicacion() completa

Antes de escribir npm install, la comprobación que ya sabes hacer:

Resultado del análisis para los paquetes de esta lección:

Que helmet y express-rate-limit tengan cero dependencias es exactamente el tipo de dato que buscabas en el módulo 5: menos código de terceros, menos superficie, menos riesgo de que un mantenedor comprometido acabe en tu node_modules. Y como siempre, cuidado con el tipogrifo: los paquetes se llaman helmet (no helmetjs), cors (no express-cors) y express-rate-limit (no express-ratelimit). Instálalos con npm install helmet cors morgan compression express-rate-limit y comprueba después con npm ls --all --parseable | wc -l cuánto ha crecido el árbol y con npm audit si algo viene con vulnerabilidades.

Qué problema resuelve. Los navegadores implementan una decena de mecanismos de defensa que solo se activan si el servidor los pide con cabeceras; sin ellas se comportan de la forma más permisiva posible. Basta con aplicacion.use(helmet()), y estas son las cabeceras que aparecen:

Qué pasa si no lo pones: todas esas defensas quedan desactivadas. Ninguna es imprescindible por sí sola ni sustituye a validar la entrada, pero juntas convierten varios ataques posibles en imposibles por una línea de código.

Aquí está el problema práctico. La CSP por defecto de helmet incluye script-src 'self', lo que bloquea todo JavaScript en línea. Si publico/index.html tiene un <button onclick="comprar('ses-001-1')"> o un <script> con constantes de las salas, ambas cosas dejarán de funcionar y en la consola del navegador aparecerá Refused to execute inline script because it violates the following Content-Security-Policy directive. La reacción instintiva es desactivar la CSP. No lo hagas: es la única cabecera de la lista que de verdad para un XSS. Las salidas correctas, por orden de preferencia: saca el JavaScript en línea a publico/app.js y usa addEventListener en lugar de onclick (una hora de trabajo y arregla el problema para siempre); si algún script en línea es inevitable, usa un nonce por respuesta; y solo como último recurso relaja la directiva concreta, nunca la CSP entera.

API pura sin front-end: si Escena Viva solo sirviera JSON, la CSP sería casi irrelevante y podrías dejar helmet() por defecto. El conflicto aparece porque servimos publico/.

Qué problema resuelve. El navegador aplica la política del mismo origen: una página solo lee respuestas de su mismo origen (esquema + host + puerto).

Cuando no coinciden, el navegador hace la petición pero oculta la respuesta al JavaScript salvo que el servidor autorice con Access-Control-Allow-Origin. Ojo con el matiz: CORS no protege tu servidor, protege al usuario del navegador; un curl o un script en Node lo ignoran por completo.

Para peticiones "no simples" —cualquier POST con Content-Type: application/json, o con cabeceras personalizadas como X-Id-Peticion— el navegador envía antes un OPTIONS preguntando permiso:

Y solo si esa respuesta autoriza, el navegador envía el POST real. Access-Control-Max-Age es importante para el rendimiento: sin él, el navegador repite el OPTIONS antes de cada petición.

La advertencia sobre credentials. Si activas credentials: true, el navegador envía cookies y cabeceras de autenticación en las peticiones entre orígenes, lo que abre la puerta a que otra web actúe en nombre del usuario con sesión abierta. Tres reglas si algún día lo necesitas (módulo 8): credentials: true exige un origen concreto, porque con '*' el navegador rechaza la respuesta; nunca devuelvas dinámicamente el Origin recibido sin comprobarlo contra la lista blanca, porque eso es una lista blanca falsa que acepta a cualquiera; y combínalo con cookies SameSite=Lax o Strict y protección CSRF. Qué pasa si no lo pones: el publico/app.js servido desde otro puerto recibirá el clásico blocked by CORS policy y no verá ni una respuesta. Si en producción el front-end se sirve desde el mismo origen que la API, CORS no hace falta: es el escenario más seguro.

Qué problema resuelve. Deja constancia de cada petición en un formato estándar que las herramientas de análisis saben leer. En 06-04 escribiste tu propio registro; morgan hace lo mismo con formatos consolidados y tokens propios.

En producción los registros se consultan con herramientas que necesitan JSON por línea, no texto legible; morgan lo permite definiendo tokens y pasando un stream propio:

Con esto, morgan sustituye a crearRegistroPeticiones de 06-04 (mantén el tuyo si te gusta más: hacen lo mismo, y ahora entiendes por dentro el de terceros). La opción skip evita llenar los registros con los sondeos de salud del orquestador. Qué pasa si no lo pones: cuando algo falle en producción no tendrás ni idea de qué pidió el cliente, ni cuándo, ni cuánto tardó. Depurar a ciegas.

Qué problema resuelve. El JSON comprime extraordinariamente bien: el catálogo completo de Escena Viva puede pasar de 12 KB a menos de 2 KB, y menos bytes es menos tiempo de carga y menos coste de tránsito.

Comprimir lo ya comprimido gasta CPU y a veces aumenta el tamaño. El filter por defecto de compression ya consulta la tabla de tipos MIME y evita esos casos.

En muchos despliegues (módulo 11) la compresión la hace Nginx o el CDN, no Node. Comprimir en Node funciona en cualquier despliegue sin configuración externa y es imprescindible si no hay proxy delante; comprimir en el proxy libera CPU del proceso y suele traer brotli optimizado y caché de respuestas comprimidas, pero exige control de ese proxy.

Regla práctica: actívala en Node por defecto; si más adelante mides que la CPU es el cuello de botella y hay un proxy delante, desactívala allí, pero nunca en los dos sitios a la vez. Para comprobarla, compara curl -s -H 'Accept-Encoding: gzip' -o /dev/null -w '%{size_download}\n' localhost:3000/api/eventos con la misma llamada sin la cabecera. Qué pasa si no lo pones: nada se rompe; simplemente envías tres o cuatro veces más bytes de los necesarios en cada respuesta.

Qué problema resuelve. Nada impide que un script llame a POST /api/pedidos en bucle: con 1189 entradas libres en el catálogo y una petición cada 20 ms, el Auditorio Ribera se queda sin aforo en menos de medio minuto. También protege de la fuerza bruta contra el inicio de sesión del módulo 8.

Al superarlo, el cliente recibe un 429 Too Many Requests con RateLimit-Limit: 5, RateLimit-Remaining: 0, RateLimit-Reset: 43 y Retry-After: 43. RateLimit-Remaining le dice cuántas peticiones le quedan y Retry-After cuántos segundos esperar; un cliente bien hecho las respeta en lugar de reintentar a ciegas.

Dos limitaciones que debes conocer ahora. Primera: el almacén por defecto es la memoria del proceso, así que con varios procesos (cluster del módulo 10) o varias instancias (módulo 11) cada uno lleva su cuenta y el límite real se multiplica; la solución es un almacén compartido en Redis (módulo 10). Segunda: depende de req.ip, que a su vez depende de trust proxy; mal configurado, o todos los clientes comparten la IP del proxy y se bloquean entre sí, o cualquiera falsifica la suya con una cabecera. En el módulo 8 profundizaremos con límites por usuario autenticado, ventanas deslizantes y retardo progresivo. Qué pasa si no lo pones: un solo cliente puede agotar el aforo, saturar el proceso o probar contraseñas sin límite.

aplicacion.use(cookieParser(configuracion.clavePasarela)) interpreta la cabecera Cookie y deja las cookies en req.cookies (y las firmadas en req.signedCookies). Escena Viva todavía no lo necesita: la API es anónima, no hay sesión y ningún endpoint depende de quién eres.

Lo dejamos anunciado porque en el módulo 8 aparecerán las sesiones con Passport y las cookies httpOnly, secure y SameSite, y entonces este middleware será el primero de la lista. Instalarlo ahora "por si acaso" sería añadir superficie sin necesidad: la disciplina del módulo 5 también consiste en no instalar lo que no usas.

Este es el código final del módulo, comentado línea a línea. El orden no es arbitrario: cada posición tiene un motivo.

Las siete reglas de orden, para memorizarlas: identificador primero (todo lo demás lo referencia); seguridad pronto (que las cabeceras lleguen también a errores y estáticos); CORS antes de los límites (el OPTIONS previo no debe consumir cupo); límites antes del cuerpo (no gastar CPU parseando lo que vas a rechazar); cuerpo antes de las rutas (req.body no existe si no); 404 después de las rutas (solo captura lo no atendido); y errores el último (solo ve lo registrado antes que él). Y las banderas registrar y limitar no son un capricho: en el módulo 9 las pondrás a false para que las pruebas no llenen la salida de registros ni fallen al superar el límite en la petición número 301.

• Desactivar la CSP entera porque rompe el front-end. Es tirar la única defensa real contra XSS. Saca el JavaScript en línea a un fichero o usa nonces.
• origin: '*' con credentials: true. El navegador rechaza la combinación. Y si "lo arreglas" devolviendo el Origin recibido sin comprobarlo, has construido una lista blanca que acepta a todo el mundo.
• Creer que CORS protege el servidor. Protege al usuario del navegador; la autorización de verdad llega en el módulo 8.
• Poner el limitador después de express.json() (parseas 100 KB antes de rechazar) o usarlo con memoria y varios procesos (con cuatro trabajadores el límite real es cuádruple; Redis en el módulo 10).
• Comprimir imágenes o vídeo, o comprimir en Node y en el proxy a la vez. Gastas CPU para no ganar bytes: deja el filter por defecto y elige un solo sitio.
• Instalar cookie-parser sin usar cookies. Superficie gratis: instálalo cuando lo necesites.
• morgan('dev') en producción. Los códigos de color son secuencias de escape que ensucian los ficheros de registro; usa combined o tu formateador JSON.
• Consejo: añade npm audit --audit-level=high al script comprobar. Cada uno de estos paquetes es código de terceros que se ejecuta en cada petición.

Para los cinco paquetes de esta lección, construye una tabla con: versión actual, licencia, fecha de la última publicación, número de dependencias directas y si aparece en npm audit. Decide justificadamente si aceptarías cada uno en un proyecto real y qué alternativa buscarías si alguno llevara dos años sin publicar.

Configura cors para que acepte http://localhost:5173 y https://escenaviva.test y rechace el resto. Demuestra con curl los tres casos: la petición de verificación previa OPTIONS desde un origen permitido (debe devolver las cabeceras Access-Control-Allow-*), un GET desde un origen no permitido (no debe llevar Access-Control-Allow-Origin) y un GET sin cabecera Origin (debe funcionar con normalidad).

Aplica limiteCompra a POST /api/pedidos con 5 peticiones por minuto. Escribe un script que lance 8 pedidos seguidos de 1 entrada para ses-001-1 e imprima el estado y las cabeceras RateLimit-* de cada uno. Comprueba que las tres últimas devuelven 429 con Retry-After y que el cuerpo respeta el formato { error: { codigo, mensaje, estado } }.

Solución 1

Criterios que deberías haber aplicado: licencia permisiva, publicación en los últimos 12-18 meses, pocas dependencias directas y de mantenedores reconocibles. Si cors llevara dos años sin publicar, la respuesta razonable no es abandonarlo —es un paquete pequeño y estable— sino vigilar sus incidencias abiertas y estar dispuesto a sustituirlo por un middleware propio de veinte líneas, porque CORS al final son cuatro cabeceras.

Solución 2

El tercer caso demuestra el punto clave: CORS es una defensa del navegador, no del servidor.

Solución 3

Salida esperada: los intentos 1 a 5 devuelven 201 con RateLimit-Remaining bajando de 4 a 0; el 6, el 7 y el 8 devuelven 429 con Retry-After: 52. Sin el limitador, los ocho habrían vendido entrada; con el aforo de ses-001-1, un bucle sin freno lo agota en segundos.

Escena Viva sale ya con el kit mínimo de una API en producción. helmet añade una decena de cabeceras de seguridad por una línea, con el matiz importante de que su CSP obliga a sacar el JavaScript en línea del front-end —y esa es la solución correcta, no desactivarla—. cors autoriza a publico/app.js a llamar a la API desde otro origen mediante una lista blanca leída de la configuración, nunca con '*', y ahora sabes qué es una petición de verificación previa y por qué credentials merece respeto. morgan registra cada petición en formato estándar y, con tokens propios, en JSON por línea listo para el módulo 11. compression recorta el tamaño de las respuestas cuando compensa. Y express-rate-limit impide que un script agote el aforo, con la advertencia de que su almacén en memoria no sobrevive a varios procesos.

Sobre todo, has visto la versión completa de crearAplicacion() con las siete reglas de orden razonadas: identificador primero, seguridad pronto, CORS antes de los límites, límites antes del cuerpo, cuerpo antes de las rutas, 404 después de las rutas y errores el último. Pero queda un agujero muy grande: POST /api/pedidos sigue haciendo registrarPedido(peticion.body) con lo que venga en el cuerpo —una cantidad de -5, un sesionId que es un objeto, un correo de 40 000 caracteres—, y ningún middleware de esta lección mira el contenido de los datos.

En la siguiente lección, Validación de Datos de Entrada, cerramos ese agujero: por qué nunca se confía en el cliente aunque el formulario valide, dónde debe vivir la validación (en el borde, no en el dominio), los esquemas de zod para los pedidos de Escena Viva, un middleware genérico validar(esquema, origen) que deja el resultado en req.datosValidados —y que respeta que req.query sea de solo lectura—, y cómo devolver un 400 que de verdad ayude a quien llama sin revelar lo que no debe.