La seguridad de API de GraphQL es el conjunto de prácticas y tecnologías que se utilizan para proteger las API de GraphQL frente al acceso no autorizado, las peticiones maliciosas, la exposición de datos, los ataques de denegación de servicio y el abuso.
GraphQL, que es un lenguaje de consulta de código abierto, ofrece a los clientes (ordenadores, teléfonos o navegadores, programas de software) una flexibilidad considerable sobre los datos que solicitan. En lugar de depender de endpoints predefinidos que devuelven respuestas fijas, los clientes pueden construir consultas que especifican los campos y los datos relacionados que necesitan.
Esa flexibilidad puede hacer que las interfaces de programación de aplicaciones sean más eficientes para los desarrolladores, pero también introduce consideraciones de seguridad específicas. Una interfaz de programación de aplicaciones GraphQL mal protegida puede permitir que los atacantes construyan consultas computacionalmente costosas, descubran partes sensibles del esquema de una interfaz de programación de aplicaciones, accedan a datos para los que no están autorizados o automaticen un gran número de peticiones maliciosas.
Por lo tanto, la seguridad eficaz de GraphQL requiere una combinación de autenticación, autorización, control de consultas, validación de entradas, limitación de frecuencia, seguridad de la aplicación, supervisión y diseño de API seguro.
¿Qué herramientas y prácticas componen la seguridad de API de GraphQL?
La seguridad de API de GraphQL protege los datos, las Operaciones y la infraestructura expuestos a través de una interfaz de programación de aplicaciones GraphQL. Una interfaz de programación de aplicaciones GraphQL suele exponer un esquema que describe los tipos de datos disponibles y las Operaciones que los clientes pueden realizar. Los clientes envían consulta o mutaciones en las que describen la información o las acciones que quieren.
La protección de las API de GraphQL implica prácticas y herramientas en torno a:
Autenticación
autorización
Validación de entrada
Controles de profundidad y complejidad de las consultas
Gestión de esquemas e introspección
Protección contra inyecciones
Gestión de errores
Registros y supervisión
El objetivo es proporcionar a los clientes legítimos las capacidades que necesitan, sin restringir la flexibilidad de GraphQL.
¿Cómo funciona la seguridad de API de GraphQL?
Una petición de GraphQL suele llegar a un único endpoint HTTP, como «/graphql». La petición contiene una consulta que describe la operación que el cliente quiere que el servidor realice. Un cliente legítimo podría solicitar información sobre un producto y su disponibilidad.
El servidor de GraphQL analiza la consulta, la valida con el esquema, invoca los resolvers necesarios, recupera los datos adecuados y devuelve una respuesta.
Los controles de seguridad se pueden aplicar en varias fases de ese proceso.
La autenticación identifica al cliente
La autenticación determina quién o qué está realizando la petición. Las API de GraphQL pueden usar mecanismos como cookie de sesión, claves de API, OAuth o JSON Web Tokens (JWT), según la arquitectura de la aplicación.
La autorización controla lo que el cliente puede hacer
La autenticación por sí sola no es suficiente. Después de identificar al cliente, la aplicación debe determinar si esa identidad tiene permiso para acceder a un objeto, campo u operación concretos.
La autorización debe aplicarse en la capa de lógica de negocio en lugar de depender únicamente de los resolvers de GraphQL o de ocultar partes del esquema.
Los controles de consulta limitan las operaciones costosas
Las consultas de GraphQL pueden anidarse. Sin los controles adecuados, un cliente podría enviar una consulta que requiera una cantidad considerable de CPU, memoria, trabajo de base de datos o llamadas a servicios descendentes.
Las aplicaciones pueden analizar la profundidad, la amplitud, la complejidad o el coste de la consulta y rechazar las peticiones que superen los límites aceptables.
La limitación de frecuencia controla el consumo de peticiones
El límite de volumen puede controlar la frecuencia con la que los clientes realizan Operaciones. En GraphQL, las organizaciones pueden necesitar un control más sofisticado que simplemente contar peticiones HTTP, porque dos peticiones al mismo endpoint /graphql pueden tener costes computacionales radicalmente distintos.
Los controles de seguridad de las aplicaciones inspeccionan el tráfico malicioso
Una aplicación web firewall (WAF) o una plataforma de protección de aplicaciones web y API pueden inspeccionar las peticiones en busca de ataques como la inyección y otras cargas útiles maliciosas antes de que lleguen a la aplicación GraphQL.
La monitorización detecta comportamientos inusuales
Los registros y la telemetría de seguridad pueden revelar patrones de consulta inesperados, fallos repetidos de autorización, peticiones inusualmente costosas, bots maliciosos o picos de tráfico. En conjunto, estos controles proporcionan defensa en profundidad en torno a la API de GraphQL.
¿Por qué es necesaria la seguridad de API de GraphQL?
GraphQL no hace que una interfaz de programación de aplicaciones sea insegura de forma inherente. Sin embargo, algunas de las características que hacen que GraphQL sea potente también generan consideraciones de seguridad que difieren de las de las interfaces de programación de aplicaciones REST convencionales.
A continuación se indican los riesgos derivados de la naturaleza de GraphQL y las razones por las que la seguridad de API de GraphQL es tan importante.
Los clientes tienen un control significativo sobre las consultas
Con una interfaz de programación de aplicaciones REST, el servidor suele definir endpoints que devuelven estructuras de datos predeterminadas. En su lugar, GraphQL permite que el cliente especifique los campos y las relaciones que quiere. Sin las restricciones adecuadas, un cliente malicioso puede utilizar potencialmente esa flexibilidad para construir consultas costosas o abusivas.
Un único endpoint puede exponer muchas operaciones
La seguridad de API tradicional suele utilizar las rutas de URL como parte importante de la política de seguridad. GraphQL suele enrutar muchas consultas y mutaciones diferentes a través del mismo endpoint. Por lo tanto, un sistema de seguridad no puede asumir que todas las peticiones a /graphql representan la misma operación o el mismo riesgo.
Las consultas pueden llegar a ser computacionalmente costosas
GraphQL permite relaciones anidadas. Una consulta profundamente anidada o excepcionalmente amplia puede provocar muchas llamadas a resolvedores, operaciones de base de datos o petición a servicios posteriores. Los atacantes pueden aprovechar intencionadamente este comportamiento para consumir recursos de la aplicación.
La autorización puede volverse granular
Es posible que se permita a un usuario acceder a un objeto GraphQL, pero no a otro, o a algunos campos de un objeto, pero no a otros. Por lo tanto, cada operación relevante de acceso a datos necesita la autorización adecuada.
La información del esquema puede ayudar a los atacantes
GraphQL admite la introspección, que permite a los clientes consultar información sobre el esquema. Esto es extremadamente útil para las herramientas de desarrollo. Sin embargo, en producción, las organizaciones deben tomar una decisión deliberada sobre si la introspección sin restricciones es necesaria, porque la información del esquema puede ayudar a un atacante a comprender las Operaciones disponibles.
Las API atraen abusos automatizados
Los atacantes pueden usar bots para realizar reconocimiento, ataques de credenciales, consultar operaciones costosas, extraer datos o intentar la explotación a escala. Por lo tanto, la seguridad de GraphQL debe abordar tanto las vulnerabilidades como el abuso de la funcionalidad legítima.
¿Cuáles son los riesgos habituales de seguridad de API de GraphQL?
Autorización dañada
Una interfaz de programación de aplicaciones puede autenticar correctamente a un usuario, pero no verificar si ese usuario debe tener permiso para acceder a un objeto o campo concreto. Por ejemplo, cambiar un identificador de objeto en una consulta no debería permitir que un cliente recupere la información privada de otro cliente.
Profundidad excesiva de la consulta
Un atacante puede construir consultas profundamente anidadas que requieren cantidades cada vez mayores de procesamiento. Los límites de profundidad pueden evitar que las peticiones superen los requisitos razonables de anidamiento de una aplicación.
Complejidad de las consultas y agotamiento de recursos
La profundidad no es la única preocupación - una consulta relativamente superficial podría solicitar miles de objetos o invocar resolvedores costosos. El análisis del coste o la complejidad de las consultas puede proporcionar una protección más precisa al estimar los recursos necesarios para ejecutar una petición.
Abuso del procesamiento por lotes
Las implementaciones de GraphQL pueden permitir que se envíen varias operaciones juntas. Aunque el procesamiento por lotes puede mejorar la eficiencia de las aplicaciones legítimas, los atacantes pueden intentar usarlo para eludir límites de volumen simples basados en peticiones o realizar un gran número de operaciones en menos peticiones HTTP.
ataque por inyección
Los resolutores de GraphQL interactúan con frecuencia con bases de datos y otros sistemas de backend. Si la entrada del usuario se gestiona de forma insegura en fases posteriores, las aplicaciones GraphQL pueden seguir siendo vulnerables a la inyección SQL, la inyección de comandos y otros ataques por inyección.
Divulgación de información
Los errores detallados pueden exponer trazas de pila, detalles internos de implementación u otra información útil para los atacantes. La introspección del esquema también puede revelar información sobre los tipos y las operaciones disponibles cuando está habilitada.
denegación de servicio
Las consultas costosas, los alias excesivos, el procesamiento por lotes, las peticiones repetidas u otras operaciones que consumen muchos recursos pueden utilizarse para degradar el rendimiento o la disponibilidad de la aplicación.
Scraping automatizado y abuso
Una consulta GraphQL técnicamente válida puede seguir siendo abusiva cuando se ejecuta automáticamente a gran escala. La gestión de bots y la limitación de frecuencia pueden ser complementos importantes para la seguridad de API centrada en vulnerabilidades.
¿Cuáles son las prácticas recomendadas para la seguridad de API de GraphQL?
La seguridad de GraphQL debe comenzar con la propia aplicación y reforzarse con controles de seguridad en tiempo de ejecución.
1. Requerir una autenticación fuerte
Protege las operaciones no públicas con mecanismos de autenticación adecuados. Usa estándares de identidad consolidados y una gestión segura de sesiones o tokens en lugar de crear sistemas de autenticación personalizados sin una razón de peso.
2. Aplicar la autorización en cada nivel pertinente
No des por hecho que los usuarios autenticados deban tener acceso a todos los objetos expuestos a través del esquema. La autorización debe estar vinculada a las reglas de negocio de la aplicación y aplicarse de forma coherente cuando se accede a los datos o se modifican.
3. Limitar la profundidad de la consulta
Establece límites razonables sobre la profundidad con la que se pueden anidar las consultas. El máximo adecuado depende de los requisitos legítimos de la aplicación.
4. Implementar el análisis del coste de las consultas
Asigna costes a campos u operaciones en función del consumo de recursos previsto y rechaza las peticiones cuyo coste calculado supere un umbral aceptable. Esto puede proporcionar una protección más significativa que los límites de profundidad por sí solos.
5. Aplicar límite de volumen
Aplica límites de volumen a los clientes según el riesgo de la aplicación y los patrones de uso normales. Cuando sea posible, ten en cuenta la operación o el coste real del recurso de GraphQL en lugar de tratar cada petición HTTP como equivalente.
6. Control de lotes y alias
Establece límites razonables sobre cuántas operaciones, alias o campos puede solicitar un cliente a la vez. Esto puede reducir las oportunidades de eludir los límites de volumen convencionales o crear cargas de trabajo inesperadamente costosas.
7. Validar todas las entradas
Trata los argumentos de GraphQL como entradas no fiables. Usa validación de esquemas, consultas de base de datos parametrizadas, API seguras y un tratamiento de la salida adecuado al contexto.
8. Toma una decisión intencionada sobre la introspección
La introspección es valiosa para el desarrollo y las herramientas, pero el acceso en producción debe ajustarse a los requisitos de la organización. Deshabilitar o restringir la introspección no sustituye a la autorización, pero puede reducir la exposición innecesaria de información.
9. Evita los detalles de error excesivos
Devuelve errores útiles a los clientes legítimos sin exponer trazas de pila, información de la base de datos, detalles del servicio interno ni otra información confidencial de implementación.
10. Usa tiempos de espera
No se debe permitir que las consultas consuman recursos del servidor indefinidamente. Los tiempos de espera adecuados de ejecución, base de datos y servicios descendentes pueden limitar el impacto de operaciones inesperadamente costosas.
11. Protege el endpoint de GraphQL con un WAF
Un WAF puede proporcionar un nivel adicional de seguridad frente a peticiones maliciosas a la aplicación. No debe sustituir un diseño seguro de GraphQL, pero puede ayudar a evitar que los ataques lleguen a componentes vulnerables de la aplicación.
12. Supervisar el tráfico de GraphQL
Haz un seguimiento de las tasas de peticiones, los errores, los fallos de autenticación, los patrones de operación, la complejidad de las consultas, la latencia del backend y el consumo de recursos. Una observabilidad eficaz facilita la identificación de ataques y problemas de rendimiento antes de que afecten significativamente a los usuarios.
¿Quién necesita seguridad de API de GraphQL?
Cualquier organización que exponga interfaces de programación de aplicaciones de GraphQL debería implementar control de seguridad adecuados, pero esta necesidad cobra especial importancia en el caso de las interfaces de programación de aplicaciones que gestionan datos sensibles, grandes volúmenes de tráfico u Operaciones empresariales valiosas.
Proveedores de Saas
GraphQL puede permitir que las aplicaciones de frontend recuperen datos complejos de clientes y aplicaciones de forma eficiente. Una autorización sólida es esencial en entornos multiinquilino para evitar que los datos crucen los límites entre clientes.
Empresas de comercio electrónico
Las API de GraphQL pueden exponer catálogos de productos, cuentas de clientes, carritos, inventario, funcionalidad de pago y otras operaciones de alto valor. Estas API pueden atraer scraping, ataques de credenciales, fraude y ataques de disponibilidad.
Servicios financieros
Las API que gestionan información financiera o personal requieren una autenticación sólida, autorización, supervisión y prevención del abuso.
Empresas de medios de comunicación y editoriales
GraphQL puede proporcionar acceso flexible a grandes bibliotecas de contenido, pero también puede convertirse en un objetivo de scraping no autorizado y consultas que consumen muchos recursos.
Desarrolladores de móviles y aplicaciones
GraphQL es útil cuando distintos clientes necesitan diferentes subconjuntos de datos. Las aplicaciones móviles siguen comunicándose con API accesibles públicamente, por lo que un atacante puede interactuar directamente con la API en lugar de usar la aplicación oficial.
Empresas que utilizan microservicios
GraphQL puede proporcionar un nivel de interfaz de programación de aplicaciones unificado sobre varios servicios de backend. Eso hace que la seguridad sea especialmente importante, porque una interfaz de GraphQL puede proporcionar acceso a datos y funcionalidad distribuidos en numerosos sistemas internos.
¿Cómo puede Fastly ayudar a proteger las API de GraphQL?
Fastly ofrece varias capacidades de seguridad que pueden complementar los controles implementados en una aplicación GraphQL.
Fastly Next-Gen WAF
WAF de última generación de Fastly protege las aplicaciones web y las API frente a peticiones maliciosas. Utiliza la tecnología de detección SmartParse de Fastly para analizar los parámetros de las peticiones e identificar el comportamiento malicioso de la aplicación, en lugar de depender exclusivamente de la coincidencia tradicional de expresiones regulares.
Esto puede proporcionar una capa adicional de protección frente a inyecciones y otros ataques de capa de la aplicación dirigidos a las API de GraphQL.
Capacidades de seguridad de API de Fastly
Las capacidades de protección de aplicaciones web y API de Fastly pueden ayudar a las organizaciones a proteger las API junto con las aplicaciones web tradicionales. Situar la seguridad en el edge permite inspeccionar las peticiones maliciosas antes de que consuman recursos de la aplicación GraphQL, la base de datos o el servicio backend.
Esto resulta especialmente útil en arquitecturas GraphQL, donde una petición puede desencadenar potencialmente una cantidad considerable de trabajo posterior.
Fastly Bot Management
Una petición de GraphQL no necesita aprovechar una vulnerabilidad para causar daños. Los atacantes pueden usar clientes automatizados para extraer datos, sondear esquemas y operaciones, intentar ataques a cuentas o invocar repetidamente consultas costosas.
Fastly Bot Management ayuda a identificar y gestionar el tráfico automatizado para que las organizaciones puedan aplicar el control adecuado a los bots no deseados, al tiempo que preservan el acceso de los usuarios legítimos y la automatización aprobada.
Limitación de frecuencia
Las capacidades de limitación de frecuencia de Fastly pueden ayudar a controlar el tráfico excesivo antes de que llegue a las aplicaciones protegidas. En entornos GraphQL, la limitación de frecuencia en el edge puede complementar controles a nivel de aplicación, como el análisis del coste de las consultas. El edge puede restringir la actividad excesiva de peticiones, mientras que el servidor GraphQL aplica políticas más detalladas en función del coste real y de los requisitos de autorización de cada operación.
DDoS Protection
Los endpoints de GraphQL pueden convertirse en objetivos de ataques DDoS de capa de la aplicación, especialmente cuando los atacantes identifican consultas que consumen recursos de backend desproporcionados. DDoS Protection puede ayudar a detectar y mitigar el tráfico malicioso en el edge, reduciendo la cantidad de tráfico de ataque que llega a la infraestructura de la aplicación.
Entrega en el edge y almacenamiento en caché
Cuando las respuestas de GraphQL se pueden almacenar en caché de forma segura, las capacidades de distribución de Fastly pueden reducir las peticiones repetidas a la infraestructura de GraphQL. El almacenamiento en caché de GraphQL requiere un diseño cuidadoso porque las respuestas pueden depender de consultas, variables, autenticación y datos específicos del usuario. Las organizaciones solo deben almacenar en caché las respuestas cuando las claves y políticas de caché representen con precisión esas variaciones.
Cuando se implementa correctamente, el almacenamiento en caché en el edge puede reducir las peticiones al backend y mejorar el rendimiento de API.
Visibilidad en tiempo real
Fastly proporciona registro en tiempo real y visibilidad de seguridad que pueden ayudar a los equipos a investigar actividad sospechosa en la interfaz de programación de aplicaciones. En los despliegues de GraphQL, esto puede complementar la observabilidad a nivel de aplicación al proporcionar a los equipos de seguridad y Operaciones visibilidad del tráfico antes de que llegue al servicio GraphQL.
¿Cómo encaja Fastly en una estrategia de seguridad de GraphQL?
Fastly se considera mejor como un nivel adicional de seguridad en torno a una aplicación GraphQL correctamente protegida, no como un sustituto de la seguridad dentro de la implementación de GraphQL.
La aplicación debe seguir siendo responsable de controles como los siguientes:
Autenticación
Autorización a nivel de objeto y de campo
Límites de profundidad de consulta
Análisis de complejidad o coste de las consultas
Implementación segura del resolvedor
Validación de entrada
Gestión segura de errores
Políticas de introspección adecuadas
Fastly puede complementar esos controles con WAF de última generación, Protección de API, Bot Management, limitación de frecuencia, DDoS Protection, entrega en el edge y visibilidad en tiempo real.
En conjunto, estos niveles pueden ayudar a las organizaciones a bloquear peticiones maliciosas antes de que lleguen a la infraestructura de GraphQL, controlar el abuso automatizado, reducir el impacto de las avalanchas de tráfico, proteger las API frente a ataques a la aplicación y limitar el consumo innecesario de recursos del backend.
El principio central de la seguridad de API de GraphQL es preservar la flexibilidad de GraphQL sin dar a los clientes un control ilimitado sobre los recursos o los datos de la aplicación. Combinar un diseño seguro de GraphQL con la protección de aplicaciones y API basada en edge puede ayudar a las organizaciones a lograr ese equilibrio.