Versiones viejas y entornos olvidados

El Top 10 de OWASP para APIs (edición 2023) dedica un riesgo entero a esto: la gestión inadecuada del inventario (API9:2023). La idea es sencilla. Las APIs exponen muchas más rutas que una aplicación web tradicional, cambian de versión con frecuencia y se despliegan en varios entornos; si el inventario no está completo y al día, quedan versiones antiguas y puntos de prueba expuestos que nadie protege ni vigila.

Un inventario útil para seguridad no es una lista de nombres. Por cada API y versión dice dónde vive (host y entorno), quién responde por ella, qué datos maneja, si está expuesta a internet, en qué estado está y, si se retira, cuándo deja de responder de verdad. Y se contrasta con fuentes que no dependen de la memoria de nadie: la zona de nombres, la configuración de la pasarela y del balanceador, y el tráfico.

Abre el laboratorio y pon inventario-apis.csv al lado de zona-dns.txt. Toda entrada de la zona que responde como API tiene que estar en el inventario. Descarta lo que la propia zona dice que es otra cosa y usa registro-balanceador.txt para confirmar qué hosts sirven rutas de API.

Retirar una versión en el inventario no la apaga. Lo que dice si sigue viva es el tráfico. El inventario marca la versión 1 de socios como retirada desde el 30 de junio, y el registro es de noviembre.

Cuenta las peticiones a la versión 1 de la API de socios en el host de producción. No cuentes las del host de pruebas ni las de otras APIs que también usan el prefijo /v1.

Compara la operación de beneficios en socios-v1.yaml y en socios-v2.yaml, y lee nota-retiro.txt. Luego busca en el registro quién llama a esa operación en la versión vieja.

Una versión retirada no se apaga de un día para otro: primero hay que saber quién depende de ella y migrarlo, mientras la pasarela protege la versión vieja igual que a la nueva o la deja responder solo a ese consumidor. El registro dice quién es.