Identidad del inquilino en cada petición

Cuando alguien inicia sesión, la plataforma emite un token firmado que dice, entre otras cosas, a qué inquilino pertenece esa sesión. Ese dato lo fijó la plataforma, no el cliente, y el cliente no puede cambiarlo sin romper la firma. Todo lo demás que llega con una petición (el parámetro de una URL, una cabecera, un campo del cuerpo) lo escribe quien hace la petición y puede decir lo que quiera.

La regla de diseño es sencilla: el inquilino de una petición sale del token firmado, se obtiene en un punto común antes de llegar a la lógica de cada servicio y se contrasta con cualquier identificador de inquilino que traiga la ruta. Si no coinciden, la petición se rechaza.

La ficha del diseño declara, servicio por servicio, de dónde toma el inquilino y si lo contrasta con el token. Un servicio que lo toma de un parámetro y no lo verifica ha delegado su aislamiento en el cliente. Los otros pueden estar bien o mal construidos por dentro, pero al menos su decisión no depende de un valor ajeno.

Abre SELECT * FROM servicios.

En el registro de peticiones, la columna «inquilino_token» es el inquilino de la sesión y «inquilino_pedido» es el inquilino cuyos datos pedía la ruta. Cuando difieren, hay dos desenlaces posibles: una negativa (estado 403, sin filas) que muestra que el control funcionó, o una respuesta con filas (estado 200), que muestra que no. El registro no dice qué contenían las filas, pero sí que salieron.

Abre SELECT * FROM peticiones y busca las peticiones en las que los dos inquilinos no coinciden.

Alguien que prueba valores de inquilino uno tras otro deja un rastro reconocible: la misma sesión, varias peticiones seguidas, el inquilino pedido cambiando cada vez. Medir cuánto duró la ráfaga sirve para acotar la ventana que hay que revisar en otros registros, como los de la base de datos o los de otros servicios. No dice quién estaba detrás ni con qué intención: eso pertenece a otra investigación.

Con las peticiones en las que el inquilino pedido no coincide con el de la sesión, resta la hora de la primera a la de la última.

El hallazgo no se arregla escondiendo los identificadores ni frenando el ritmo de las peticiones: el defecto es dónde se decide el inquilino. La corrección debe llevar esa decisión a un punto común que lea el token, y debe haber una segunda barrera en la capa de datos (la política de filas de la sala anterior) por si una ruta se olvida. Además, hay que revisar las demás rutas del mismo servicio: un defecto de diseño rara vez está en una sola.