Con la identidad verificada (07-01) y el canal cifrado (07-02), un atacante ya no puede leer el token de Ana ni hacerse pasar por Pedidos. Pero puede seguir siendo un usuario legítimo que envía una petición malintencionada: un id con caracteres extraños, un JSON de 50 MB, un filtro de MongoDB disfrazado de cadena, o simplemente GET /v1/pedidos/ped-88214 para ver si cuela. Esta lección trata de lo que cada servicio hace con lo que recibe y con lo que guarda: los principios que ordenan todo lo demás, el OWASP API Security Top 10 recorrido con ejemplos de TechCorp, validación y saneamiento de entrada con zod, las inyecciones (SQL, NoSQL, comandos, logs), cabeceras con helmet, dependencias, secretos en el código, protección de datos personales (RGPD a nivel práctico), auditoría, pruebas de seguridad y respuesta ante vulnerabilidades. Termina con la lista de comprobación que se incorpora a la plantilla techcorp/plantilla-servicio-node. Autenticación (07-01), TLS (07-02) y contenedores/Kubernetes (07-04) solo se enlazan.

Aviso. Las medidas de esta lección son las habituales en un equipo de desarrollo, no un programa de seguridad completo. La aplicación real del RGPD, de PCI DSS y de cualquier política de retención o auditoría debe revisarse con un profesional de seguridad y con el responsable de cumplimiento/protección de datos de la organización.

1. Principios que ordenan el resto
2. OWASP API Security Top 10 (2023) con ejemplos de TechCorp
3. Validación y saneamiento de entrada con zod
4. Inyección: SQL, NoSQL, comandos y logs
5. Cabeceras de seguridad con helmet
6. Gestión de dependencias
7. Secretos en el código: nunca, y cómo asegurarlo
8. Protección de datos personales: RGPD en la práctica
9. Auditoría de acciones sensibles
10. Pruebas de seguridad: SAST, DAST, revisión y pentest
11. Respuesta ante vulnerabilidades
12. Lista de comprobación de seguridad por servicio

Seis principios que se repiten en cada decisión de este módulo:

El OWASP API Security Top 10 es la lista de referencia de riesgos en APIs. Recorrerla con casos propios es la mejor forma de interiorizarla:

Los remedios ya existen en su mayoría en el código de TechCorp; esta lección los reúne y añade los que faltan.

Regla: todo lo que entra por la red se valida contra un esquema antes de tocarlo, tanto lo que viene del usuario como lo que viene de otro servicio o de un evento. En 04-02 y 04-04 ya se hace con zod; aquí se endurece:

Y en las rutas, también los parámetros de ruta, que muchos olvidan:

Y en app.js los límites globales que ya traía la plantilla, ahora justificados: express.json({ limit: '100kb', strict: true }) (un cuerpo mayor → 413; strict rechaza JSON que no sea objeto o array), y en el gateway proxy-body-size: 2m en el Ingress (05-02) como techo absoluto. Saneamiento frente a validación: TechCorp prefiere rechazar (400) a "limpiar" silenciosamente; la única normalización aceptada es trim() y la de mayúsculas en códigos (pais.toUpperCase()), y siempre en el esquema, nunca dispersa.

La inyección ocurre cuando datos del usuario se interpretan como código o estructura. Cuatro variantes que afectan a TechCorp:

SQL (PostgreSQL con pg). Nunca concatenar; siempre parámetros posicionales, como ya hace PedidoRepositorio en 04-04:

NoSQL (MongoDB en Catálogo). El riesgo es distinto: no es texto, sino objetos. Si una ruta hace coleccion.find({ sku: req.query.sku }) y el cliente envía ?sku[$ne]=x, Express (con qs) construye { sku: { $ne: 'x' } } y la consulta devuelve todos los productos; con $where o $regex puede ser peor. Regla: nunca pasar objetos del usuario al filtro; validar con zod que cada valor es una cadena (o número) y construir el filtro en el repositorio con las claves fijas:

Además, express.json no interpreta operadores, pero un cuerpo { "filtro": { "$where": "..." } } sí llegaría como objeto: mismo remedio (esquema .strict(), nada de filtro libre).

Comandos del sistema. Casi nunca hacen falta en un servicio; si los hay (generar un PDF, convertir una imagen), execFile('convert', [ruta]) con argumentos en array, jamás exec(\convert ${nombre}`)`, y el nombre de fichero validado con patrón. Mejor aún: una librería nativa.

Logs. El log injection: un usuario pone en calle el texto "Gran Vía 12\n{\"nivel\":\"info\",\"mensaje\":\"pedido pagado\"}" y, si el log fuera texto, aparecería una línea falsa. Con pino (06-01) el valor va serializado dentro de un JSON (los saltos de línea se escapan como \n), así que la estructura no se rompe; la regla es no construir mensajes concatenando entrada del usuario (log.info(\pedido de ${nombre}`)) sino pasarla como campo (log.info({ clienteId }, 'pedido creado')`), y recordar que los datos personales no van al log en ningún caso (apartado 8).

helmet es un conjunto de middlewares de Express que fija cabeceras HTTP defensivas. En el gateway (lo que ve el navegador) y en cada servicio (defensa en profundidad; y algunos, como el BFF, sirven HTML):

helmet no sustituye a CORS (03-04): CORS dice desde qué origen puede llamar el navegador; helmet dice cómo debe tratar el navegador la respuesta.

Un servicio-pedidos típico arrastra 300 paquetes transitivos; la mayoría de las vulnerabilidades reales entran por ahí. La política de TechCorp:

Y npm audit en CI no es infalible: revisa el aviso, no lo silencies con --force; si no hay parche, evalúa el riesgo (¿la función vulnerable se usa?) y documenta la excepción con fecha de revisión.

La regla existe desde 04-03 (los secretos llegan por el entorno o ficheros _FILE, nunca en el repositorio ni en la imagen); aquí se hace verificable:

Y en local, un hook de pre-commit con gitleaks protect --staged. Si un secreto llega al repositorio, la única respuesta correcta es rotarlo (el historial de git es público para siempre para quien lo haya clonado): la mecánica de rotación —Secrets, External Secrets, reinicios— es de 07-04. Añade a .gitignore de la plantilla .env, *.pem, *.key; y recuerda que un secreto en un console.log, en una traza de error o en la URL de una petición (?token=) también es una fuga: por eso redact (06-01) y configParaLog() (04-03).

TechCorp trata datos personales de Ana (nombre, correo, dirección) y datos de pago. Sin pretender sustituir al responsable de protección de datos, las decisiones técnicas que un equipo debe tomar:

• Minimización. ¿Debe pedido.creado llevar cliente.email y nombre (02-02)? Se necesitan para que Notificaciones envíe el correo sin llamar a Clientes (autonomía, 03-02). Alternativas: (a) el evento lleva los datos y todos los consumidores los reciben (Inventario no los necesita); (b) el evento lleva solo clienteId y Notificaciones consulta GET /v1/clientes/{id} con su token de servicio. Decisión de TechCorp: (a) por autonomía y porque Notificaciones es el único suscriptor que los usa hoy, con tres condiciones: los datos personales solo van en pedido.creado (no en el resto de eventos de la saga), RabbitMQ va cifrado (07-02) y las colas y la DLQ tienen retención limitada (mensajes en .dlq más de 7 días se purgan tras revisarse: no son un archivo); y se revisará hacia (b) si aparece un segundo consumidor que no los necesita.
• Seudonimización. Fuera de Clientes, los servicios guardan clienteId, no el nombre; los logs y métricas llevan solo identificadores (06-01); las trazas de Jaeger no llevan cuerpos.
• Cifrado en reposo. En las bases de datos gestionadas está activo por defecto (discos cifrados); para columnas especialmente sensibles se puede cifrar a nivel de aplicación con una clave del gestor de secretos, a costa de no poder indexarlas. Copias de seguridad cifradas y con la misma retención.
• Derecho de supresión. El flujo de 02-04: servicio-clientes anonimiza y publica cliente.eliminado; Pedidos borra clientes_ref y anonimiza direcciones de pedidos antiguos que la normativa fiscal obligue a conservar; Notificaciones no guarda nada. Es un caso de uso más, con prueba automatizada.
• Datos de tarjeta: NUNCA en TechCorp. El navegador envía la tarjeta directamente a la pasarela (formulario o SDK del proveedor); TechCorp recibe un token (tok_…) que servicio-pagos usa para cobrar. Así el alcance de PCI DSS se reduce al mínimo (SAQ A). Ni el número, ni el CVV, ni siquiera "los cuatro últimos dígitos" salvo que la pasarela los devuelva ya enmascarados. *.tarjeta en redact es una red por si alguien se equivoca, no un permiso.
• Registro de tratamientos y retención: cada servicio documenta qué datos personales guarda, para qué y cuánto tiempo (tabla en su README), y un CronJob aplica la retención (p. ej. anonimizar direcciones de pedidos de más de 5 años).

Los logs de 06-01 cuentan qué pasó técnicamente; la auditoría cuenta quién hizo qué sobre qué, y debe poder demostrarse meses después. Acciones auditables en TechCorp: cancelar un pedido (quién, motivo), cambiar un precio en Catálogo, cambiar el estado de un pago manualmente, reprocesar la DLQ (scripts/reprocesarDlq.js, 06-03), acceder a datos de un cliente por parte de un operador, cambiar roles en Keycloak. Requisitos: inmutable (solo inserción, sin UPDATE/DELETE para el usuario svc_*), separado de los logs operativos (retención distinta: años frente a semanas), y correlacionable con X-Request-Id y el sub del token (X-Usuario-Id, 07-01).

Con volumen alto, la tabla se sustituye por eventos auditoria.* a un almacén de solo escritura (o el log estructurado con tipo: 'auditoria' enviado a un tenant de Loki con retención larga y sin borrado); lo importante es la separación y la inmutabilidad, no la tecnología. detalle no contiene datos personales: identificadores y valores de negocio.

Y las pruebas de seguridad de aplicación son pruebas normales: el test/pedidos.auth.test.js de 07-01 (401/403/404) y casos como "un id que no cumple el patrón devuelve 400", "un cuerpo con campo desconocido devuelve 400", "?categoria[$ne]=x devuelve 400" viven en Jest junto al resto y protegen contra regresiones.

Antes o después alguien encontrará algo. Lo que TechCorp deja preparado:

1. Canal de reporte: [email protected] y un fichero /.well-known/security.txt en shop.techcorp.example (RFC 9116) con contacto y política; agradecimiento público (sin recompensa formal en la fase 1).
2. Triaje: gravedad con CVSS; crítica/alta → incidente de seguridad con el proceso de 06-05 (canal, responsable, cronología), aunque no haya caída de servicio.
3. Parcheo: rama desde main, prueba que reproduce el fallo, despliegue por el pipeline normal (canary si aplica, 05-04); dependencia vulnerable → actualización o mitigación temporal (bloquear la ruta en el gateway).
4. Comunicación: interna (todos los equipos, porque el mismo patrón puede estar en otro servicio) y, si ha habido acceso a datos personales, notificación a la autoridad de control en 72 horas y a los afectados según el RGPD: decisión del responsable de protección de datos, no del equipo técnico.
5. Postmortem sin culpa (06-05) con acciones: nueva regla de Semgrep, nuevo caso en la lista de comprobación, prueba de regresión.

Esta tabla se añade a techcorp/plantilla-servicio-node/SEGURIDAD.md y a la plantilla de pull request; cada servicio la revisa al crearse y en cada cambio relevante:

• Validar solo el cuerpo y dejar req.params.id y req.query sin esquema: la mitad de las inyecciones y BOLA entran por ahí.
• Esquemas permisivos (z.object sin .strict(), z.string() sin max) que aceptan cualquier campo o cadenas de 10 MB: la validación debe ser tan estricta como el contrato OpenAPI.
• "Sanear" en vez de rechazar: quitar caracteres "peligrosos" con expresiones regulares caseras nunca cubre todos los casos y cambia los datos del usuario a escondidas.
• Confiar en la respuesta de terceros porque "es la pasarela": API10 existe porque los terceros también se equivocan y también los atacan.
• Loguear el cuerpo de la petición en info "para depurar" y descubrir semanas después que Loki guarda direcciones y correos.
• Silenciar npm audit con --force o audit-level=critical para que CI pase: cada excepción, documentada con fecha.
• Considerar la auditoría "un log más" y borrarla a los 30 días con la retención de Loki.
• Consejo: cada regla de esta lección que se pueda automatizar (lint, Semgrep, gitleaks, ZAP, prueba Jest) vale más que la misma regla en un documento; la lista de comprobación es para lo que no se puede automatizar.

Ejercicio 1. Un desarrollador propone añadir a servicio-catalogo la ruta GET /v1/productos/buscar?filtro=<json> que recibe un objeto de filtro de MongoDB "para que el front pueda hacer consultas flexibles". Explica el problema con la numeración de OWASP y propón un diseño seguro que cubra las necesidades reales (buscar por texto, categoría y rango de precio).

Ejercicio 2. Escribe el esquema zod para POST /v1/pedidos/{id}/cancelacion (03-01: motivo de una lista permitida, comentario opcional) incluyendo el parámetro de ruta, y el registro de auditoría correspondiente con crearAuditoria.

Ejercicio 3. Marta pregunta si, para cumplir el RGPD, basta con que Notificaciones "borre el correo cuando llegue cliente.eliminado". Enumera qué otros lugares de la plataforma pueden contener el correo de Ana y qué medida aplica a cada uno.

Solución 1. Es API8/API3 y una inyección NoSQL de manual: un objeto de filtro arbitrario permite { "$where": "..." }, { "precio": { "$gt": 0 } } sobre campos que no debían filtrarse, exponer campos internos (costeProveedor), consultas sin índice que tumban Mongo (API4) y, con $lookup en agregaciones, leer otras colecciones. Diseño seguro: parámetros con nombre y esquema cerrado, Busqueda = z.object({ q: z.string().trim().min(2).max(60).optional(), categoria: z.string().regex(/^[a-z-]{1,40}$/).optional(), precioMin: z.coerce.number().min(0).optional(), precioMax: z.coerce.number().max(100000).optional(), limite: ...máx 100, cursor }).strict(); el repositorio construye el filtro con claves fijas ({ nombreNormalizado: { $regex: escapar(q), $options: 'i' } } con q escapado o, mejor, un índice de texto y $text: { $search: q }; precioCentimos: { $gte, $lte }); solo campos indexados; y la ruta devuelve el DTO aDto de siempre. Si el front necesita algo más flexible, es un caso para GraphQL en el BFF (03-03), con esquema tipado, no para pasar objetos de Mongo.

Solución 2.

El comentario no va a la auditoría (texto libre del usuario, puede contener datos personales): solo si existe. Y la auditoría se registra después de la transición, dentro de la misma transacción si el repositorio lo permite, para no auditar cancelaciones que fallaron.

Solución 3. Lugares y medidas: (1) Base de datos de Clientes: anonimizar la fila (no borrar, por integridad y obligaciones fiscales), origen del evento. (2) clientes_ref en Pedidos (02-04): borrar la fila y anonimizar direccion_envio de pedidos antiguos al recibir cliente.eliminado. (3) Mensajes pedido.creado en colas, .reintento y .dlq de RabbitMQ: retención corta y purga (apartado 8); si hay mensajes en DLQ del cliente, se procesan o descartan. (4) Logs en Loki: no debería haber correo gracias a redact y a la regla de no loguearlo; si una auditoría encuentra alguno, es un incidente (apartado 11) y hay que borrarlo del almacén. (5) Trazas en Jaeger: sin cuerpos ni datos personales por diseño (06-02); comprobar los atributos de span propios. (6) Copias de seguridad: no se editan; se documenta que el dato desaparece al expirar la retención de la copia (y se anonimiza al restaurar). (7) Keycloak: borrar o desactivar el usuario (el sub), que es donde vive el correo de login. (8) Proveedor de correo de Notificaciones (si conserva historial de envíos): configurar retención mínima o solicitar borrado por su API. (9) La tabla de auditoría: no debe contener correos (solo usuario_id), y por diseño se conserva. La respuesta a Marta: "borrar en Notificaciones" es una de nueve acciones, y por eso el derecho de supresión es un caso de uso con lista y prueba, no un DELETE.

Esta lección ha convertido la seguridad "del código" en prácticas concretas de TechCorp: seis principios (mínimo privilegio, defensa en profundidad, fallar seguro, superficie mínima, seguridad por diseño, shift left); el OWASP API Security Top 10 leído con casos propios y remedios que ya existían (propietario del recurso, DTOs, limite ≤ 100, rate limit, CORS, OpenAPI y Pact) o se han añadido; esquemas zod .strict() con ids por patrón (^ped-[0-9a-f]{8}$), listas blancas y límites, también en parámetros de ruta y query, con express.json({ limit: '100kb' }); consultas parametrizadas en pg, filtros de MongoDB con claves fijas, execFile y logs por campos; helmet en gateway y servicios; npm ci, npm audit, Dependabot y SBOM; gitleaks en CI y rotación ante cualquier fuga; RGPD práctico (minimización con la decisión de mantener email en pedido.creado bajo condiciones, seudonimización, cifrado en reposo, cliente.eliminado, retención, y nunca datos de tarjeta: tokenización de la pasarela y alcance PCI DSS mínimo); auditoría inmutable y separada con crearAuditoria correlacionada por usuario_id y request_id; SAST con ESLint/Semgrep, DAST con ZAP contra staging, revisión con lista y pentest anual; un proceso de respuesta con security.txt y notificación RGPD; y la lista de comprobación que ahora forma parte de plantilla-servicio-node. Queda la última capa, la que sostiene a todas las demás: la imagen que ejecuta el código, el pod que la contiene, los secretos que le llegan, la red que lo rodea y los permisos del clúster. Es el tema de la siguiente lección: seguridad en contenedores y Kubernetes.