¿Qué es la seguridad de la API de GraphQL?
La seguridad de la API de GraphQL es el conjunto de prácticas y tecnologías que se utilizan para proteger las API de GraphQL del acceso no autorizado, las solicitudes 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, brinda a los clientes (computadoras, teléfonos o navegador, programas de software) una flexibilidad considerable sobre los datos que solicitan. En lugar de depender de endpoints predefinidos que devuelven respuesta fijas, los clientes pueden construir consulta que especifican los campos y los datos relacionados que necesitan.
Esa flexibilidad puede hacer que las API sean más eficientes para el desarrollador, pero también introduce consideraciones de seguridad específicas. Una API GraphQL mal protegida puede permitir que un atacante construya consultas computacionalmente costosas, descubra partes sensibles del esquema de una API, acceda a datos que no está autorizado a ver o automatice una gran cantidad de solicitudes maliciosas.
Por lo tanto, la seguridad efectiva de GraphQL requiere una combinación de autenticación, autorización, control de consultas, validación de entradas, limitación de velocidad, seguridad de la aplicación, monitoreo y Diseño de API seguro.
¿Qué herramientas y prácticas conforman la Seguridad de la API de GraphQL?
La seguridad de la API de GraphQL protege los datos, las operaciones y la infraestructura expuestos a través de una API de GraphQL. Una API de GraphQL normalmente expone un esquema que describe los tipos de datos disponibles y las operaciones que los clientes pueden realizar. Los clientes envían consultas o mutaciones 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
Control de profundidad y complejidad de las consultas
Administración de esquemas e introspección
Protección contra inyecciones
Manejo de errores
Registro y monitoreo
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 la API de GraphQL?
Una solicitud de GraphQL generalmente llega a un solo endpoint HTTP, como “/graphql”. La solicitud 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 parse la consulta, la valida con respecto al esquema, invoca los resolvers necesarios, recupera los datos adecuados y devuelve una respuesta.
Los controles de seguridad se pueden aplicar en varias etapas de ese proceso.
La autenticación identifica al cliente
La autenticación determina quién o qué está haciendo la solicitud. Las API de GraphQL pueden usar mecanismos como cookies 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 en particular.
La autorización debe aplicarse en la capa de lógica de negocio en lugar de depender únicamente de los resolvedores de GraphQL o de ocultar partes del esquema.
Los controles de consulta limitan las operaciones costosas
Las consultas de GraphQL pueden estar anidadas. 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 posteriores.
Las aplicaciones pueden analizar la profundidad, amplitud, complejidad o costo de la consulta y rechazar las solicitudes que excedan los límites aceptables.
La limitación de velocidad controla el consumo de solicitudes
Los límites de velocidad pueden controlar la frecuencia con la que los clientes realizan operaciones. Para GraphQL, las organizaciones pueden necesitar controles más sofisticados que simplemente contar solicitudes HTTP, porque dos solicitudes al mismo endpoint /graphql pueden tener costos computacionales drásticamente diferentes.
Los controles de seguridad de las aplicaciones inspeccionan el tráfico malicioso
Una firewall de aplicaciones web (WAF) o plataforma de Protección de API y aplicaciones web puede inspeccionar las solicitudes en busca de ataques como inyección y otras cargas útiles maliciosas antes de que lleguen a la aplicación GraphQL.
La supervisión detecta comportamientos inusuales
Los logs y la telemetría de seguridad pueden revelar patrones de consulta inesperados, fallas repetidas de autorización, solicitudes inusualmente costosas, bots maliciosos o picos de tráfico. En conjunto, estos controles proporcionan defensa en profundidad para la API de GraphQL.
¿Por qué es necesaria la Seguridad de la API de GraphQL?
GraphQL no hace que una API sea insegura de forma inherente. Sin embargo, algunas de las funciones que hacen que GraphQL sea potente también generan consideraciones de seguridad que difieren de las de las API REST convencionales.
Los siguientes son riesgos introducidos por la naturaleza de GraphQL y las razones por las que la Seguridad de la API de GraphQL es tan importante.
Los clientes tienen un control significativo sobre las consultas
Con una API de REST, el servidor comúnmente define endpoints que devuelven estructuras de datos predeterminadas. En cambio, GraphQL permite que el cliente especifique los campos y las relaciones que quiere. Sin las restricciones adecuadas, un cliente malicioso puede usar potencialmente esa flexibilidad para construir consultas costosas o abusivas.
Un solo endpoint puede exponer muchas operaciones
La Seguridad de la API tradicional suele usar las rutas de URL como una 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 solicitudes a /graphql representan la misma operación o riesgo.
Las consultas pueden volverse computacionalmente costosas
GraphQL permite relaciones anidadas. Una consulta profundamente anidada o excepcionalmente amplia puede provocar muchas llamadas al resolvedor, operaciones de base de datos o solicitudes posteriores. Los atacantes pueden explotar intencionalmente 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 de acceso a datos relevante necesita la autorización adecuada.
La información del esquema puede ayudar a los atacantes
GraphQL admite la introspección, lo 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, ya que la información del esquema puede ayudar a los atacantes a comprender las Operaciones disponibles.
Las API atraen el abuso automatizado
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 comunes de seguridad de la API de GraphQL?
Autorización dañada
Una API puede autenticar correctamente a un usuario, pero no verificar si ese usuario debe tener permiso para acceder a un objeto o campo en particular. 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 solicitudes excedan los requisitos razonables de anidación de una aplicación.
Complejidad de la consulta 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 costo o la complejidad de la consulta puede proporcionar una protección más precisa al estimar los recursos necesarios para ejecutar una solicitud.
Abuso 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 una aplicación legítima, un atacante puede intentar usarlo para eludir límites de velocidad simples basados en solicitudes o realizar una gran cantidad de operaciones dentro de menos solicitudes HTTP.
ataque de inyección
Los resolvers de GraphQL interactúan con frecuencia con bases de datos y otros sistemas de backend. Si la entrada del usuario se maneja de forma insegura en procesos posteriores, las aplicaciones de GraphQL pueden seguir siendo vulnerables a la inyección de SQL, la inyección de comandos y otros ataques de inyección.
Divulgación de información
Los errores detallados pueden exponer rastros de pila, detalles de implementación interna u otra información útil para los atacantes. La introspección del esquema también puede revelar información sobre los tipos y operaciones disponibles cuando está habilitada.
Denegación de servicio
Las consultas costosas, los alias excesivos, el procesamiento por lotes, las solicitudes repetidas u otras operaciones que consumen muchos recursos pueden usarse para degradar el rendimiento o la disponibilidad de la aplicación.
Scraping automatizado y abuso
Una consulta de GraphQL técnicamente válida aún puede ser abusiva cuando se ejecuta automáticamente a gran escala. La gestión de bots y la limitación de velocidad pueden ser complementos importantes para la Seguridad de la API centrada en vulnerabilidades.
¿Cuáles son las mejores prácticas de Seguridad de la 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. Requiere autenticación sólida
Protege las Operaciones no públicas con mecanismos de autenticación adecuados. Usa estándares de identidad establecidos y un manejo seguro de sesiones o token en lugar de crear esquemas de autenticación personalizados sin una razón de peso.
2. Aplica la autorización en cada capa relevante
No des por hecho que los usuarios autenticados deben 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 manera coherente cuando se accede a los datos o se modifican.
3. límite la profundidad de la consulta
Establece límites razonables sobre qué tan profundamente se pueden anidar las consultas. El máximo adecuado depende de los requisitos legítimos de la aplicación.
4. Implementa el análisis del costo de las consultas
Asigna costos a campos u operaciones según el consumo esperado de recursos y rechaza las solicitudes cuyo costo calculado supere un umbral aceptable. Esto puede brindar una protección más significativa que los límites de profundidad por sí solos.
5. Aplicar límite de velocidad
Aplica límites de velocidad a los clientes según el riesgo de la aplicación y los patrones normales de uso. Cuando sea posible, considera la operación o el costo real del recurso de GraphQL en lugar de tratar cada solicitud 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 velocidad convencionales o crear cargas de trabajo inesperadamente costosas.
7. Valida todas las entradas
Trata los argumentos de GraphQL como entrada no confiable. Usa validación de esquemas, consultas de base de datos parametrizadas, API seguras y un manejo de salida adecuado al contexto.
8. Toma una decisión intencional 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 excesivos de errores
Devuelve errores útiles a clientes legítimos sin exponer rastros de pila, información de bases de datos, detalles de servicios internos ni otra información sensible 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 para la ejecución, la base de datos y los servicios posteriores pueden limitar el impacto de operaciones inesperadamente costosas.
11. Protege el endpoint de GraphQL con una WAF
Un WAF puede proporcionar una capa adicional de seguridad contra solicitudes maliciosas a la aplicación. No debe reemplazar un diseño seguro de GraphQL, pero puede ayudar a evitar que los ataques lleguen a componentes vulnerables de la aplicación.
12. Monitorea el tráfico de GraphQL
Realiza un seguimiento de las tasas de solicitudes, errores, fallas de autenticación, patrones de operación, complejidad de las consultas, latencia del backend y consumo de recursos. La observabilidad efectiva facilita identificar ataques y problemas de rendimiento antes de que afecten significativamente a los usuarios.
¿Quién necesita seguridad de la API de GraphQL?
Cualquier organización que exponga API de GraphQL debe implementar controles de seguridad adecuados, pero la necesidad se vuelve especialmente importante para las API que manejan datos sensibles, grandes volúmenes de tráfico o operaciones comerciales valiosas.
Proveedores de Software como servicio
GraphQL puede permitir que las aplicaciones de frontend recuperen de forma eficiente datos complejos de clientes y aplicaciones. Una autorización sólida es esencial en entornos multiinquilino para evitar que los datos crucen los límites entre clientes.
Empresas de e-commerce
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 manejan información financiera o personal requieren autenticación, autorización, monitoreo y prevención de abuso sólidos.
Empresas de medios y publicación
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 aplicaciones y móviles
GraphQL es útil cuando diferentes 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 potencialmente directamente con la API en lugar de usar la aplicación oficial.
Empresas que usan microservicios
GraphQL puede proporcionar una capa de API unificada sobre múltiples 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 dentro de una aplicación GraphQL.
WAF de siguiente generación de Fastly
WAF de siguiente generación de Fastly protege las aplicaciones web y las API contra solicitudes maliciosas. Utiliza la tecnología de detección SmartParse de Fastly para analizar los parámetros de la solicitud 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 contra inyecciones y otros ataques de capa de aplicación dirigidos a las API de GraphQL.
Capacidades de Seguridad de la API de Fastly
Las capacidades de Fastly de Protección de API y aplicaciones web pueden ayudar a las organizaciones a proteger las API junto con las aplicaciones web tradicionales. Colocar la seguridad en el edge permite inspeccionar solicitudes maliciosas antes de que consuman recursos de la aplicación GraphQL, la base de datos o los servicios de backend.
Esto es particularmente útil en arquitecturas GraphQL donde una solicitud puede potencialmente activar un trabajo sustancial en procesos posteriores.
Gestión de bots de Fastly
Una solicitud de GraphQL no necesita explotar una vulnerabilidad para causar daño. 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 los controles adecuados a los bots no deseados, al tiempo que preservan el acceso para los usuarios legítimos y la automatización aprobada.
limitación de velocidad
Las capacidades de limitación de velocidad de Fastly pueden ayudar a controlar el tráfico excesivo antes de que llegue a las aplicaciones protegidas. Para entornos GraphQL, la limitación de velocidad en el edge puede complementar controles a nivel de aplicación, como el análisis del costo de las consultas. El edge puede restringir la actividad excesiva de solicitudes, mientras que el servidor GraphQL aplica políticas más detalladas según el costo real y los requisitos de autorización de cada operación.
Protección contra ataques de DDoS
Los endpoints de GraphQL pueden convertirse en objetivos de ataques DDoS de capa de aplicación, en particular cuando los atacantes identifican consultas que consumen recursos desproporcionados del backend. Protección contra ataques de DDoS de Fastly puede ayudar a detectar y mitigar el tráfico malicioso en el edge, lo que reduce la cantidad de tráfico de ataque que llega a la infraestructura de la aplicación.
Distribución 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 solicitudes repetidas a la infraestructura de GraphQL. El almacenamiento en caché de GraphQL requiere un diseño cuidadoso porque las respuestas pueden depender de las consultas, las variables, la autenticación y los datos específicos del usuario. Las organizaciones solo deben almacenar respuestas en caché cuando las claves y políticas de caché representen con precisión esas variaciones.
Cuando se implementa adecuadamente, el almacenamiento en caché en el edge puede reducir las solicitudes al backend y mejorar el rendimiento de la 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 de la API. En los despliegues de GraphQL, esto puede complementar la observabilidad en el nivel de la aplicación al brindar 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?
Es mejor considerar Fastly como una capa de seguridad adicional alrededor de una aplicación GraphQL correctamente protegida, no como un reemplazo de la seguridad dentro de la implementación de GraphQL.
La aplicación debe seguir siendo responsable de controles que incluyen:
autenticación
Autorización a nivel de objeto y de campo
Límite de profundidad de consulta
Análisis de complejidad o costo de consultas
Implementación segura del resolvedor
Validación de entrada
Manejo seguro de errores
Políticas de introspección adecuadas
Fastly puede complementar esos controles con Next-Gen WAF, Protección de API, Bot Management, limitación de velocidad, Protección contra ataques de DDoS, distribución edge y visibilidad en tiempo real.
En conjunto, estas capas pueden ayudar a las organizaciones a bloquear solicitudes maliciosas antes de que lleguen a la infraestructura de GraphQL, controlar el abuso automatizado, reducir el impacto de las inundaciones de tráfico, proteger las API contra ataques a aplicaciones y limitar el consumo innecesario de recursos de backend.
El principio central de la Seguridad de la API de GraphQL es preservar la flexibilidad de GraphQL sin dar a los clientes control ilimitado sobre los recursos o datos de la aplicación. Combinar un diseño seguro de GraphQL con protección de aplicaciones y Protección de API basada en edge puede ayudar a las organizaciones a lograr ese equilibrio.




