La API que nadie miró

vendedor-61 usa su propio token, válido y vigente, para pedir sus ventas. La misma petición, cambiando solo el id de vendedor en la ruta, le devuelve las ventas de otra cuenta: la API no comprueba que el id pedido sea el del dueño del token.

El token de vendedor-61 es válido: la API lo acepta sin problema. Lo que no comprueba es si el id de vendedor que pide coincide con el dueño del token. Esa distinción —qué tan válido es el token frente a qué objeto puede pedir con él— es la que separa un fallo de autenticación de uno de autorización, y dentro de autorización, de qué tipo.

El catálogo de productos responde con más campos de los que la app del vendedor necesita para mostrar su inventario. Entre ellos hay uno que es información interna de compras de Pórtico Digital, no un dato del producto que el vendedor deba ver.

El equipo que hizo el encargo ya probó, dentro del alcance firmado, la función de webhook que notifica entregas: el servidor visita la URL que cada vendedor configura. El registro de esa prueba, ya ejecutada y documentada, muestra que la función llegó a un servicio interno que no debería ser alcanzable desde esa función. La corrección no es bloquear un destino puntual: es cambiar cómo la función decide a dónde puede ir.

El registro de salida del servidor que ejecuta los webhooks guarda cada destino al que llegó, con su hora. Ahí está, ya escrita, la dirección a la que llegó la prueba que el equipo documentó como alcance de un servicio interno no autorizado para esa función.