Autorización en cada resolutor y en cada campo

Un resolutor es la función que devuelve el valor de un campo. Hay uno por cada campo que el esquema declara, aunque muchos sean triviales, y el servidor los encadena: resuelve la consulta raíz, y con lo que esta devuelve resuelve los campos del tipo siguiente, y así hasta donde llegue la petición. Esa cadena es la que hay que tener en la cabeza al revisar.

De ahí sale la regla práctica de la autorización en GraphQL: la comprobación tiene que estar donde se resuelve el dato, no solo en la puerta por la que se entró. Un mismo tipo se alcanza por varios caminos, y si la comprobación vive únicamente en uno de ellos, los demás la rodean sin proponérselo. MITRE llama a esta familia control de acceso inadecuado (CWE-284); cuando lo que falta es la comprobación sobre un dato concreto que se pide, la forma más cercana es la autorización ausente (CWE-862).

Abre el laboratorio y lee resolutores.txt. El extracto marca con exigeDueno los campos que comprueban que quien pregunta es la persona dueña del perfil. Recórrelos todos y, cruzando con matriz-de-acceso.txt, encuentra el campo que la matriz reserva a la persona dueña y que, sin embargo, se resuelve sin comprobar nada.

El informe necesita un número y el número sale del registro, no de las quejas. En registro-consultas.txt, la segunda columna dice qué cuenta tenía la sesión y la quinta de quién eran los datos que devolvió el campo más profundo. Cuenta las cuentas distintas que recibieron, con resultado correcto, el campo de facturación de un perfil que no era el suyo. Cuenta cuentas, no líneas, y descarta las operaciones denegadas.

El equipo tiene razón en que la consulta raíz de perfil exige rol de administración, y el registro lo confirma: la única vez que alguien la usó contra un perfil ajeno, el servidor la denegó. Y, aun así, ese mismo perfil entregó datos privados en otras seis operaciones. Mira qué operación aparece en esas líneas y qué campo del catálogo devuelve el tipo que describe a una persona.

Hay dos formas de escribir la recomendación y solo una envejece bien. Poner la comprobación que falta en ese campo cierra el caso de hoy y deja viva la causa: el próximo campo privado que alguien añada volverá a nacer sin ella, porque el valor por defecto de este servidor es responder. Lo que cambia el resultado es invertir ese valor por defecto, y que exponer un campo sea una decisión explícita, no lo que ocurre si nadie hace nada.