En el tráfico REST, el endpoint, el método y la ruta generalmente describen lo que hace una solicitud. En GraphQL, esa información vive principalmente en el cuerpo. El mismo endpoint `/graphql` puede transportar lecturas, escrituras, consultas anidadas, introspección, fragmentos y operaciones con variables. Una capa de seguridad que solo verifica URL y método no puede ver lo que GraphQL está haciendo realmente.
Cuando la introspección de GraphQL permanece abierta en producción, el esquema de la aplicación puede filtrarse. Un atacante que aprende qué tipos, campos y relaciones existen puede elaborar consultas mucho más dirigidas. Esto puede no ser exfiltración directa de datos, pero es una divulgación de información seria que mapea la superficie de ataque.
Las consultas anidadas y los fragmentos crean un riesgo diferente. Las consultas anidadas excesivamente profundas pueden imponer una carga de procesamiento pesada en el backend con una sola solicitud HTTP. El rate limiting estándar cuenta solicitudes — no ve el costo de una sola solicitud. En GraphQL, el riesgo de DoS generalmente proviene de la estructura de la consulta, no del volumen de solicitudes.
El query batching produce una brecha similar. Cuando se envían múltiples consultas en un cuerpo, el tráfico parece una única solicitud HTTP desde el exterior, pero múltiples operaciones pueden ejecutarse en el interior. Esto socava los controles clásicos de rate-limit y seguridad basados en endpoints.
TR7 GraphQL Deep Inspection examina el tráfico GraphQL con reglas WAAP basadas en patrones: los comportamientos de introspección, DoS por profundidad anidada y query batching se detectan en los alcances query, raw, json y form y se vinculan a políticas de producción.
TR7 aborda la seguridad GraphQL no reclamando conciencia del esquema, sino llevando los patrones de abuso GraphQL de producción más comunes al motor de firmas WAAP.
TR7 detecta indicadores de introspección como `__schema`, `__type`, `IntrospectionQuery` y `fragment FullType` usando reglas basadas en regex. Estas reglas pueden ejecutarse en modo block en producción y en modo monitor o con una puntuación más baja en staging.
Las consultas GraphQL excesivamente anidadas pueden generar una carga de procesamiento pesada con una sola solicitud. La familia de reglas TR7 50101 detecta cadenas profundas `{ ... { ... } }` a nivel de patrón y las incluye en la decisión WAAP con una puntuación alta.
Enviar múltiples consultas en un cuerpo puede socavar la lógica clásica de rate-limit. La regla TR7 50102 detecta patrones de consultas en lotes y permite vincular ese comportamiento a una decisión de registro, puntuación o bloqueo.
Una consulta GraphQL puede transportarse no solo en el cuerpo raw sino también en campos JSON, de formulario o de query string. Las reglas TR7 se ejecutan en los alcances query, raw, json y form, llevando diferentes implementaciones de cliente bajo la misma política WAAP.
GraphQL Deep Inspection gestiona los riesgos específicos de GraphQL con reglas WAAP basadas en firmas, selección de alcance y controles de hardening de endpoints.
La regla 50100 apunta a los patrones comúnmente utilizados en la introspección de GraphQL: `__schema`, `__type`, `IntrospectionQuery` y `fragment FullType`. El nivel de riesgo predeterminado se posiciona como una señal de fuerza media y puede evaluarse con una puntuación de 4. En los endpoints donde la introspección debe cerrarse en producción, esta regla puede ejecutarse en modo block o monitor. Los intentos de descubrimiento de esquemas se hacen visibles en el flujo de eventos WAAP.
La regla 50101 detecta consultas GraphQL excesivamente anidadas a nivel de patrón. Las cadenas profundas de `{` y las estructuras altamente anidadas pueden hacer que una sola solicitud imponga un alto costo de procesamiento en el backend. Esta regla puede evaluarse con una puntuación de 6 como una señal de ataque más fuerte. El objetivo no es realizar el cálculo de complejidad consciente del esquema — es capturar los patrones de consultas anidadas peligrosas de forma temprana.
La regla 50102 detecta patrones en lotes donde se envían múltiples consultas en un solo cuerpo. Dado que el query batching puede ser legítimo para algunos clientes, los valores de estado y puntuación de la regla deben ajustarse al comportamiento de la aplicación. Comenzar en modo monitor y clarificar con la observación del tráfico real es el enfoque correcto. Una vez confirmado el abuso, la regla puede pasarse a una política de bloqueo.
Junto con las reglas enriquecidas TR7, waf_db contiene variantes GraphQL como las familias 50100, 50101 y 21360+. Estas variantes cubren ortografías alternativas como `__schema {`, `__type`, `__typename` y patrones de mutación anidados. Esto construye una superficie de firma más amplia para los comportamientos de introspección y consultas anidadas sin depender de una sola regex. Los operadores pueden anular el estado y la puntuación de estas reglas por servicio.
Las consultas GraphQL no siempre llegan en el mismo formato. Algunos clientes envían los campos `query`, `variables` y `operationName` dentro de un cuerpo JSON; otros pueden usar cuerpo raw o campos de formulario. Las reglas TR7 se ejecutan en los alcances query, raw, json y form, llevando estos diferentes formatos de transporte a la cobertura de inspección. Esto reduce el error de confiar solo en un formato de cuerpo en los endpoints GraphQL.
Los controles GraphQL pueden aplicarse tanto a los objetivos api_endpoint como web_application. El mismo modelo de reglas WAAP puede gestionarse con diferentes valores de estado, puntuación o alcance según el tipo de servicio. Por ejemplo, la introspección puede permanecer en modo monitor en un endpoint de prueba interno mientras se bloquea en un endpoint de producción público. Esta flexibilidad permite adaptar un único conjunto de reglas a diferentes políticas de entorno.
Se pueden definir controles para el endpoint `/graphql` como permitir solo el método POST, restringir las claves JSON esperadas a `query`, `variables` y `operationName`, o aplicar un límite de tamaño del cuerpo. Estos controles no reemplazan las firmas GraphQL — son una capa de seguridad positiva que los complementa. Los métodos o campos JSON inesperados pueden rechazarse en una etapa temprana, haciendo el comportamiento del endpoint más predecible.
Si el tráfico GraphQL incluye patrones de mutación específicos de la aplicación, nombres de campos o nombres de operaciones de riesgo, pueden agregarse como reglas WAAP personalizadas. Por ejemplo, una palabra clave `mutation` específica o un nombre de operación sensible que aparece en el cuerpo puede asignarse una puntuación más alta. Estas reglas personalizadas participan en el sistema de puntuación WAAP principal y son visibles en el flujo de logs y SIEM. Incluso sin inspección de campos consciente del esquema, los riesgos específicos de la aplicación pueden capturarse con reglas basadas en patrones.
GraphQL Deep Inspection está basado en firmas en sus capacidades reales actuales — el análisis de operaciones, el cálculo de complejidad y las afirmaciones WAAP de campos conscientes del esquema están fuera del alcance de esta página.
Los controles GraphQL trabajan con un enfoque de detección de patrones basado en regex y alcance. La diferenciación de tipos de operación, un contador de profundidad real o el cálculo de puntuación de complejidad de consultas no son parte de este modelo. Esta distinción es especialmente importante para un posicionamiento preciso.
Las reglas 50100, 50101, 50102 y las variantes waf_db pueden establecerse en enabled, monitor o disabled según las necesidades del servicio. Los valores de puntuación también pueden ajustarse a la tolerancia de falsos positivos de la aplicación. El modelo de despliegue correcto para los endpoints GraphQL de producción es comenzar en modo monitor y pasar al bloqueo después de la observación del tráfico real.
La lista de métodos permitidos, la lista de claves JSON permitidas y el límite de tamaño del cuerpo pueden aplicarse en los endpoints GraphQL. Estos controles garantizan que la forma de la solicitud se ajuste al contrato esperado junto con la detección de firmas. En APIs públicas en particular, aceptar solo el formato esperado en el endpoint `/graphql` reduce la superficie de ataque.
El rate-limiting por operación no se aplica a nivel de parser GraphQL. No se reclama el análisis semántico del número de operaciones dentro de un solo cuerpo y la aplicación de un límite separado a cada una. El patrón de query batching puede capturarse como firma y usarse junto con las políticas generales de rate-limit.
No hay soporte dedicado para consultas persistidas dentro de esta capacidad. Los patrones GraphQL visibles en la solicitud se inspeccionan con firmas WAAP. La resolución de una consulta desde su hash y su verificación contra datos de esquema u operación registrada no se reclama en esta página.
No se realiza inspección nativa a nivel de un campo de esquema GraphQL específico — por ejemplo `User.email` — a nivel de campo. Las reglas trabajan con un enfoque de coincidencia de patrones contra el cuerpo. Si hay requisitos específicos de campo, deben abordarse de manera limitada y cuidadosa con una regla regex personalizada.
Un equipo de seguridad puede permitir la introspección en staging mientras ejecuta la regla 50100 en modo block en el endpoint de producción. Los intentos de descubrimiento de esquemas se registran, se puntúan y se bloquean por política.
Los fragmentos o estructuras de consulta excesivamente anidados pueden imponer un alto costo de procesamiento en el backend. La regla 50101 captura estos patrones con una puntuación de 6, proporcionando una señal fuerte para la decisión de bloqueo WAAP.
Cuando se intentan muchas consultas en una sola solicitud a un endpoint de cliente móvil, la regla 50102 detecta el patrón en lotes. El equipo de operaciones puede observar el comportamiento en modo monitor primero y pasar al modo enabled una vez confirmado el abuso.
Un equipo de API puede permitir solo el método POST y los campos JSON `query`, `variables` y `operationName` en el endpoint `/graphql`. Los métodos o campos inesperados se rechazan antes de llegar a la aplicación, reduciendo el comportamiento del endpoint.
Haga que los riesgos de introspección, DoS anidado y query batching sean visibles y gestionables en producción. Recorramos una configuración en vivo en sus propios servicios.