POST /api/pedidos sigue haciendo registrarPedido(peticion.body) con lo que llegue. Helmet, CORS y el limitador de peticiones no miran el contenido: un cuerpo con cantidad: -5, un sesionId que es un array o un correo de 40 000 caracteres pasa por todos ellos sin despeinarse. Este es el agujero que cerramos ahora. La validación es una de las cosas que Express no hace por ti (lo dijimos en 06-01, tabla incluida) y es también una de las que más consecuencias tiene cuando falta. En esta lección decidimos dónde vive, elegimos una herramienta, escribimos los esquemas de Escena Viva y construimos un middleware genérico que se coloca en la ruta y deja los datos ya limpios y convertidos.

1. Por qué nunca se confía en el cliente
2. Qué se valida y dónde debe vivir la validación
3. Validación a mano y por qué se vuelve inmantenible
4. zod: el validador elegido
5. Los esquemas de Escena Viva
6. El middleware genérico validar(esquema, origen)
7. Coerción y normalización
8. La respuesta de error útil
9. Usos menos obvios: respuestas y configuración
10. Sanitización frente a validación

publico/app.js valida el formulario antes de enviar: comprueba que la cantidad esté entre 1 y 6, que el correo tenga arroba y que haya una sesión seleccionada. Y aun así, el servidor debe volver a validarlo todo. Motivos, ordenados de más evidente a menos:

1. El cliente no es tu formulario. Cualquiera puede llamar a la API con curl, con Postman o con un script: tu HTML es una sugerencia, no un control.
2. El cliente se puede modificar. Las herramientas de desarrollo del navegador permiten cambiar el max de un input en dos segundos.
3. Puede haber más clientes. Una app móvil, un panel de taquilla, una integración con un promotor. Cada uno con sus propios fallos.
4. Los intermediarios alteran datos. Proxies, redirecciones, reintentos con cuerpo truncado.
5. El cliente valida para la experiencia; el servidor valida para la integridad. El primero evita frustración, el segundo evita corrupción.

La formulación clásica: la validación en el cliente es cortesía; la validación en el servidor es obligación. Y no se trata solo de atacantes: un despliegue del front-end que envíe cantidad como cadena en lugar de número por un error de tipado provoca exactamente el mismo destrozo, sin mala intención.

Y la pregunta más importante: ¿dónde se coloca esa validación? El recorrido es Cliente → validar() → Controlador → Servicio → Dominio, y hay dos puntos de rechazo bien distintos: el middleware validar() devuelve 400 cuando la forma es inválida, y el dominio devuelve 409 cuando el aforo no da. Son dos niveles con responsabilidades distintas, y confundirlos es un error de diseño frecuente:

La regla: el borde garantiza la forma; el dominio garantiza las reglas. Sesion.vender() no debe comprobar si cantidad es un número —eso ya está garantizado cuando llega— pero sí debe comprobar si hay aforo, porque eso depende del estado y puede cambiar entre la validación y la venta. Y al revés: si borras el middleware de validación, el dominio no debe romperse de forma catastrófica, pero tampoco es su trabajo generar mensajes amables para un cliente HTTP.

Recuerda cómo quedó rutas-pedidos.js en el módulo 4:

Cinco problemas concretos, y todos empeoran con el tiempo:

1. Se detiene en el primer error. El cliente arregla sesionId, reenvía, y descubre que también fallaba cantidad: tres viajes para tres errores.
2. No devuelve el resultado convertido. Validas datos.cantidad pero sigues usando el objeto original sin normalizar.
3. Los campos de más pasan. Si el cliente envía { cantidad: 2, esAdministrador: true }, ese campo llega intacto al dominio.
4. Es imposible de reutilizar. El mismo pedido validado desde una cola de mensajes o un script de importación necesita copiar y pegar.
5. No se puede documentar automáticamente. No hay descripción de la forma esperada; solo código imperativo que hay que leer entero.

Cincuenta líneas para cuatro campos: con veinte endpoints, esto es la mitad del proyecto.

zod invierte el enfoque: en lugar de escribir comprobaciones, describes la forma de los datos, y la biblioteca deriva de ahí la validación, la conversión y los mensajes. Se instala con npm install zod, y npm view zod license dependencies confirma lo que buscabas en el módulo 5: MIT y cero dependencias.

Comparativa breve y honesta:

Elegimos zod por tres razones que encajan con el curso: cero dependencias (criterio del módulo 5), independencia de Express (el mismo esquema sirve para la API, para un script de importación y para las pruebas del módulo 9) y porque el esquema es una fuente única de verdad que documenta la entrada mejor que cualquier comentario. Lo esencial de su API: se declara un objeto con z.object({ nombre: z.string().min(1).max(80), edad: z.number().int().positive(), correo: z.email(), canal: z.enum([...]), notas: z.string().optional(), activo: z.boolean().default(true) }) y se ejecuta con esquema.safeParse(datos) —que devuelve { success, data } o { success, error }— o con esquema.parse(datos), que devuelve los datos o lanza un ZodError.

Detalle clave: z.object() descarta por defecto las claves no declaradas. { cantidad: 2, esAdministrador: true } sale del validador como { cantidad: 2 }, así que el problema 3 del apartado anterior queda resuelto de oficio. Y si prefieres rechazar en vez de descartar, .strict() hace que la clave sobrante sea un error.

Compáralo con las cincuenta líneas imperativas del apartado 3: aquí hay más reglas, en menos espacio, y se leen como una especificación. Y LIMITE_ENTRADAS_POR_PEDIDO sigue siendo la misma constante del módulo 4: la regla no ha cambiado, solo el sitio donde se expresa.

Un solo middleware configurable que se coloca en cualquier ruta. Es una factoría, como las de 06-04.

Uso en las rutas, y controlador ya sin comprobaciones:

En Express 4 el patrón habitual era req.query = resultado.data, y funcionaba. En Express 5 req.query es un getter sin setter, y esa línea lanza TypeError: Cannot set property query of #<IncomingMessage> which has only a getter; si migras código antiguo, es uno de los primeros errores que verás. Guardar en req.datosValidados no es solo una forma de esquivar la limitación: es mejor diseño, porque deja explícito en el controlador que los datos que usa han pasado por un esquema y conserva intacto lo que llegó del cliente por si el registro necesita compararlo.

Todo lo que llega por HTTP es texto. req.params y req.query son siempre cadenas —en GET /api/eventos?pagina=2, req.query.pagina es '2', no 2—; solo req.body con Content-Type: application/json conserva tipos, y solo si el cliente los envió bien. Por eso convertir es parte de validar, no un paso posterior:

Sin bajar el correo a minúsculas, [email protected] y [email protected] son dos compradores distintos: los duplicados de datos maestros casi siempre nacen de una normalización que faltó.

Cuidado con la coerción excesiva. z.coerce.number() acepta '' como 0 y true como 1, porque usa Number() por debajo. Si eso no te vale, sé explícito: z.string().regex(/^\d+$/).transform(Number). Coerción amable en la query (donde todo es texto por fuerza), coerción estricta en el cuerpo JSON (donde el cliente pudo enviar el tipo correcto).

Mantenemos el formato fijado en el módulo 4 y le añadimos detalles:

Qué hace útil a esta respuesta: da todos los errores a la vez (un viaje en lugar de tres), el campo exacto con ruta completa en estructuras anidadas (entradas.0.cantidad), un motivo legible escrito por ti en el esquema, un tipo estable (too_big, invalid_type) que un cliente puede tratar por programa sin depender del idioma, y el identificador de petición de 06-04 para cruzarlo con los registros del servidor.

Y qué no debe aparecer nunca:

Ambos son legítimos y hay debate. Nuestra política, coherente con la tabla ESTADO_POR_CODIGO del módulo 4:

Lo importante no es cuál eliges, sino que sea coherente en toda la API y esté documentado.

Los esquemas no son solo para lo que entra.

En 06-02 escribiste funciones a mano (obligatoria, entero, lista); un esquema hace lo mismo más corto y con mejores mensajes:

El mismo principio de "fallar rápido", con un único sitio que describe todo lo que la aplicación necesita para arrancar.

src/servicios/cambio-divisas.js hace fetch a una API que no controlas: que hoy devuelva { rates: { USD: 1.08 } } no garantiza que mañana no devuelva { data: [...] } tras un cambio de versión.

El coste es mínimo y evita el peor tipo de fallo: el que no explota donde ocurre, sino tres capas más abajo con un undefined incomprensible.

Se confunden constantemente, pero son cosas distintas:

La regla que evita la mayoría de los errores: valida al entrar, escapa al salir. ¿Por qué no escapar al guardar? Porque el escapado depende del destino y guardando escapado pierdes el dato original: si guardas <script> y lo envías por JSON a una app móvil, esa app muestra literalmente <script>; si el mismo comentario va a un HTML, a un CSV y a un correo, cada destino necesita un escapado distinto; y si cambias de sistema de plantillas, tus datos ya están contaminados con el escapado del anterior.

Guarda el dato tal como es (validado, normalizado) y escapa en el punto de renderizado. En Escena Viva, el publico/app.js que pinta comentarios debe usar textContent en lugar de innerHTML: ese es el escapado correcto para ese destino.

Verás repetido que "validar previene la inyección SQL". Es falso como defensa principal: una lista negra de palabras (DROP, --, ;) se esquiva de mil maneras y rechaza comentarios legítimos de compradores llamados O'Brien. La protección real son las consultas parametrizadas, que separan el código de los datos para que el motor nunca interprete un valor como instrucción; eso llega en el módulo 7, con Mongoose y Sequelize.

Mientras tanto, en Escena Viva la persistencia es un JSON y el riesgo equivalente es distinto pero real:

• Recorrido de directorios si un identificador acaba formando parte de una ruta de fichero. Por eso resolverDentroDe sigue siendo obligatorio (módulo 3).
• Contaminación de prototipo si haces Object.assign({}, req.body) con una clave __proto__. zod te protege porque z.object() descarta lo no declarado.
• Denegación de servicio con cuerpos enormes o regex catastróficas. Por eso limit en express.json() y patrones acotados en los esquemas.

Validar reduce superficie, pero no sustituye a la defensa específica de cada destino.

• Confiar en la validación del formulario o reasignar req.query/req.params (TypeError en Express 5): el HTML es cortesía, el servidor es la frontera real, y el resultado va a req.datosValidados.
• Validar dentro del dominio. Sesion.vender() no debe comprobar tipos: cuando llega ahí ya son correctos. Su trabajo es el aforo.
• Devolver solo el primer error (obliga al cliente a un viaje por campo; safeParse los da todos) o filtrar el error interno: nunca envíes trazas ni valores recibidos, regístralos en el servidor y devuelve lo justo.
• Coerción indiscriminada (z.coerce.number() convierte '' en 0 y true en 1) u olvidar .trim() (un ' ses-001-1 ' falla contra la regex con un mensaje desconcertante).
• Duplicar los esquemas entre rutas. Extrae los fragmentos comunes (idSesion, correoComprador) y compónlos.
• Consejo: el esquema es documentación ejecutable. Cuando alguien pregunte qué acepta POST /api/pedidos, la respuesta es src/esquemas/pedido.js, y no puede estar desactualizada porque es el código que se ejecuta.

Escena Viva quiere permitir pedidos con entradas para varias sesiones a la vez. Escribe esquemaCrearPedidoMultiple con email, canal y entradas, un array de 1 a 4 elementos con sesionId y cantidad. Añade dos reglas que un esquema de campo aislado no puede expresar: el total de entradas no puede pasar de 6, y no puede repetirse la misma sesionId. Pista: .superRefine() sobre el objeto completo.

Aplica validar(esquemaConsultaEventos, 'query') a GET /api/eventos y adapta el controlador para leer de req.datosValidados.query. Comprueba con curl que ?porPagina=999 y ?pagina=abc devuelven 400 con el campo y el motivo, que ?agotado=true llega como booleano y que sin query los valores por defecto son pagina: 1, porPagina: 10.

Envía a POST /api/pedidos un cuerpo con un campo no declarado, por ejemplo {"sesionId":"ses-002-1","cantidad":2,"email":"[email protected]","precioCentimos":1}. Comprueba que el pedido se crea y que precioCentimos no llega al servicio. Después modifica el esquema con .strict() y comprueba que ahora devuelve 400 indicando la clave sobrante. Razona en qué casos preferirías cada comportamiento.

Solución 1

superRefine es el sitio de las reglas que cruzan campos. Ojo: siguen siendo reglas de forma, no de estado. "¿Hay aforo para estas 6 entradas?" sigue siendo del dominio, porque depende de las ventas del momento.

Solución 2

Compara el controlador con la versión del ejercicio de 06-03: han desaparecido los parseInt, los ?? y los topes manuales. Esa lógica no se ha perdido, se ha mudado al esquema.

Solución 3

Cuándo preferir cada uno: podar (el comportamiento por defecto) encaja en una API pública con clientes variados, porque un cliente antiguo que envía campos obsoletos sigue funcionando; .strict() encaja en una API interna o con campos sensibles, porque un campo inesperado suele ser un error del cliente y conviene avisar pronto. Lo crucial en ambos casos: precioCentimos jamás debe salir del cuerpo del cliente; el precio lo pone el servidor leyendo la sesión. Si un campo del cuerpo puede alterar el dinero, tienes un problema mucho más grave que un esquema mal configurado.

La validación es la frontera de tu aplicación, y ahora Escena Viva la tiene bien puesta. Sabes por qué el formulario del navegador no cuenta, qué se valida (cuerpo, parámetros, query, cabeceras) y —lo más importante conceptualmente— dónde vive cada cosa: el borde garantiza la forma, el dominio garantiza las reglas que dependen del estado; el primero devuelve 400, el segundo 409. Has cambiado las cincuenta líneas imperativas del módulo 4 por esquemas declarativos de zod que son a la vez validación, conversión, normalización, poda de campos sobrantes y documentación ejecutable. El middleware validar(esquema, origen) se coloca en cualquier ruta, deja el resultado en req.datosValidados respetando que req.query sea de solo lectura en Express 5, y libera a los controladores de toda comprobación. Y has visto los usos menos obvios —validar la configuración de arranque y las respuestas de servicios externos— además de la distinción entre validar al entrar y escapar al salir, con la advertencia honesta de que la defensa real contra la inyección son las consultas parametrizadas del módulo 7.

Queda un detalle sin resolver, y es el que cierra el módulo: el middleware validar no responde, llama a siguiente(new ErrorDeValidacion(...)), y ese ErrorDeValidacion no existe todavía ni nadie lo está recogiendo. Lo mismo pasa con el EVENTO_NO_ENCONTRADO que propaga cargarEvento, con el AFORO_INSUFICIENTE que lanza el dominio, con el JSON malformado que rechaza express.json() y con el 404 de las rutas inexistentes.

En la siguiente lección, Manejo de Errores, construimos el destino de todos ellos: el middleware de error de cuatro argumentos, una jerarquía propia en src/errores.js, el sitio definitivo de la tabla ESTADO_POR_CODIGO que escribiste en el módulo 4, la distinción entre errores operativos y errores de programación, y la política de qué hacer cuando algo falla fuera del alcance de Express.