Seguridad de GraphQL (GraphQL security)

Un servicio GraphQL expone un único endpoint y un esquema que describe cada tipo, campo, argumento y relación. El cliente envía una consulta nombrando los campos que quiere; el servidor resuelve cada campo, muchas veces con una función distinta por campo, y devuelve exactamente esa forma. La introspección forma parte de la especificación: al esquema se le puede preguntar por su propia definición, que es como las herramientas de desarrollo descubren la API.

Como la resolución es por campo, la autorización tiene que ser también por campo. Una comprobación hecha una sola vez en el punto de entrada no puede ser correcta, porque una única consulta puede recorrer desde un objeto que pertenece a quien llama hasta otro que no, a través de una relación que el esquema expone.

Cuatro cosas, en el orden en que solemos encontrarlas. La introspección dejada activa en producción, que nos entrega el mapa completo de tipos y argumentos, incluidos los campos que no usa ningún cliente; desactivarla merece la pena, pero es ofuscación y no un control, porque el esquema se puede recuperar por otros medios. La autorización implantada en el resolver del objeto raíz y ausente en los resolvers anidados, que es una autorización rota a nivel de objeto alcanzada por una relación en lugar de por un identificador.

Después, el coste. Las selecciones anidadas y recursivas permiten que una petición pequeña genere una cantidad enorme de trabajo, y los alias permiten que una sola petición repita el mismo campo cientos de veces, con lo que una petición HTTP se convierte en cientos de operaciones y derrota en silencio cualquier limitación de tasa que cuente peticiones. Los límites de profundidad de consulta, la puntuación de complejidad y las consultas persistidas son la respuesta, y el coste hay que contarlo en trabajo de los resolvers y no en peticiones.

Por último, agrupar varias operaciones en una misma petición es una forma bien conocida de romper códigos y credenciales por fuerza bruta sin disparar contadores escritos para un intento por petición.

Recuperamos el esquema, construimos con él el conjunto de consultas y después probamos relaciones en lugar de endpoints, porque el fallo vive en el recorrido. El informe nombra la consulta, el camino a través del grafo y los datos devueltos a los que quien llamaba no tenía derecho, más el coste medido de la consulta más cara que hemos podido componer. Comprobamos también si el endpoint acepta operaciones por GET, lo que reabre las preguntas sobre cacheo y sobre CSRF. Esto forma parte de cómo probamos un endpoint GraphQL.