Las reglas de tráfico tradicionales suelen decidir basándose en host, path, método y cabecera. En el tráfico moderno de APIs, sin embargo, el valor de decisión real generalmente vive dentro del cuerpo JSON. El rol de un usuario, la identidad del tenant, el tipo de transacción, el importe, el código de producto o el nombre de operación GraphQL pueden no aparecer en la URL en absoluto.
Esto deja al operador con dos malas opciones. O se introduce lógica adicional de enrutamiento y seguridad en el código de la aplicación, o el ADC permanece ciego en el nivel de cabecera y path. Ningún enfoque es adecuado para la seguridad moderna de APIs.
En servicios que utilizan JWT, el mismo problema existe dentro del token. Solo el valor de la cabecera Authorization es visible en la superficie; el rol, grupo, tenant o scope necesario para la decisión está almacenado en el payload del JWT. Si esos campos no pueden leerse, la política de tráfico no puede usar el contexto de identidad.
El modelo correcto es hacer que el cuerpo JSON y el contenido JWT sean parte nativa del lenguaje de expresiones. Las consultas JSONPath deben ser utilizables junto con condiciones de tráfico, reglas de seguridad, enriquecimiento de logs y acciones de enmascaramiento de datos — todo en el mismo lugar.
TR7 Operaciones JSON Path ofrece este modelo: JSONQUERY, JWTHEADER y JWTPAYLOAD vinculan el contenido de la API a las decisiones del ADC y WAAP.
TR7 lee el contenido JSON a través del motor de expresiones FX y lo lleva a las reglas de tráfico, controles de seguridad, enriquecimiento de logs y edición de respuestas.
JSONQUERY apunta a campos específicos en el cuerpo de la solicitud o respuesta usando una expresión JSONPath. Esos campos pueden entonces usarse como condiciones de tráfico, entradas ACL o valores de log.
Los campos de cabecera y payload dentro de un JWT pueden leerse usando la misma semántica JSONPath. El rol, scope, tenant o identidad de usuario puede incorporarse a las decisiones de tráfico.
Los valores dentro del cuerpo se convierten en condiciones tan naturales como las comprobaciones de path o cabecera. Las acciones pueden seleccionarse basándose en `$.tenant_id`, `$.user.role` o `$.operationName` igual que cualquier otra expresión.
Los campos JSON sensibles pueden enmascararse o sustituirse en el lado de la respuesta. La prevención de fugas de datos se aplica no solo en los logs sino directamente en el cuerpo devuelto al cliente.
Operaciones JSON Path conecta el cuerpo JSON y el contenido JWT a las capas de reglas, seguridad, log y enmascaramiento de TR7.
JSONQUERY consulta campos JSON anidados directamente dentro del cuerpo. Expresiones como `$.user.role`, `$.items[0].sku` o `$.payment.amount` pueden evaluarse como condiciones de regla. Los operadores pueden actuar sobre datos de decisión que nunca emergen en la URL o cabeceras. Esto hace posible gestionar el tráfico de API por su contexto de contenido real.
TR7 puede usar un campo leído desde JSON como condición de una regla de tráfico. Por ejemplo, el tráfico puede enrutarse a diferentes pools de backend basándose en el valor `tenant_id`. Si el valor de `role` no es aceptable, la solicitud puede rechazarse. Se establece una política de tráfico consciente del cuerpo sin modificar el código de la aplicación.
La función JWTPAYLOAD puede leer campos de claim dentro del token. El rol de usuario, grupo, scope, tenant o identidad de aplicación puede incluirse en la decisión de tráfico de esta manera. Esto evita que la cabecera Authorization sea tratada solo como un token raw. TR7 convierte el contenido del token en una señal de política.
La función JWTHEADER puede leer los campos de cabecera del token. Pueden realizarse comprobaciones de metadatos de algoritmo, key ID o tipo de token. Esta información puede usarse en reglas de seguridad, entradas de log o escenarios de acceso condicional. El token se convierte en un objeto auditable, no solo en un valor de paso.
Algunas aplicaciones transportan estructuras de datos similares a JSON en campos de cabecera personalizados. TR7 puede tratar esos campos también como señales analizables dentro del motor de expresiones. Los datos estructurados en cabeceras — no solo en el cuerpo — se incorporan a la evaluación de reglas. Esta flexibilidad importa en escenarios de integración legacy.
En escenarios de API gateway, valores como `operation`, `tenant`, `region` o `product` dentro del cuerpo pueden servir como señales de enrutamiento. TR7 puede reenviar tráfico a diferentes pools de backend basándose en esos campos. Esto permite la separación multi-aplicación o multi-tenant bajo un único endpoint. La lógica de enrutamiento no necesita estar integrada en el código de la aplicación.
Campos seleccionados del cuerpo JSON o del JWT pueden agregarse a las líneas de log. El email del usuario, la identidad del tenant, el tipo de transacción o la puntuación de riesgo pueden aparecer como campos dedicados en el log. Esto fortalece la correlación SIEM. Extraer solo los campos necesarios en lugar de registrar el cuerpo completo también contribuye a la minimización de datos.
TR7 puede proteger valores sensibles en el cuerpo de respuesta JSON usando acciones de mask o replace. Números de tarjeta, documentos de identidad, IDs de pacientes, direcciones de email o campos similares pueden apuntarse por regex o por path. Esto reduce el riesgo de fuga de datos sin requerir cambios de código del equipo de la aplicación. Funciona en capas junto con la capacidad de enmascaramiento de datos sensibles.
Los campos permitidos o requeridos dentro del cuerpo JSON pueden vincularse a una política de seguridad. Los campos desconocidos, los parámetros requeridos faltantes o las estructuras excesivamente anidadas pueden bloquearse. Esto reduce la deriva del schema de API y la superficie de inyección. La inspección del contenido JSON va más allá de las firmas de seguridad negativa.
Los payloads JSON que están profundamente anidados o contienen claves excesivas pueden agotar los recursos de la aplicación y del parser. TR7 puede imponer límites como la profundidad de anidamiento JSON y el recuento de claves como política de seguridad. Esto reduce el impacto de los intentos de DoS de API y las estructuras de cuerpo inesperadas. Los límites pueden ajustarse por sensibilidad del endpoint.
Si JSON no puede analizarse, la solicitud no se trata como un cuerpo de API de confianza. TR7 puede rechazar o registrar solicitudes con JSON malformado antes de reenviarlas al backend. Esto reduce los errores de análisis inesperados en la capa de aplicación. También proporciona visibilidad para distinguir el tráfico de ataques de los clientes con mal comportamiento.
Un resultado de JSONQUERY puede usarse junto con funciones de string, regex, map, list, IP o hash. Por ejemplo, un valor de tenant se extrae de JSON, se busca en una tabla de mapa, y el resultado impulsa una decisión de enrutamiento o bloqueo. Esto convierte la consulta JSON en parte del motor de políticas, no solo en un ayudante independiente. Las decisiones complejas de API pueden expresarse en el editor visual de reglas.
Las operaciones JSON se operan junto con el buffering del cuerpo, el manejo de errores de análisis, el comportamiento de campos JWT, la minimización de logs, la edición de respuestas y los límites de rendimiento.
El cuerpo debe ser legible antes de que pueda ejecutarse una consulta JSON. Las reglas conscientes del cuerpo requieren por lo tanto más procesamiento que las reglas solo de cabeceras. Deben aplicarse únicamente en los endpoints donde sean genuinamente necesarias.
Si JSON no puede analizarse, la política puede producir un rechazo, una entrada de log o una acción diferente. Si un endpoint de API espera JSON, un payload malformado no debería reenviarse al backend. Este comportamiento mejora la seguridad del endpoint.
Leer el contenido JWT y verificar el token no son la misma operación. Si los valores de claim JWT van a usarse en decisiones de tráfico, la verificación de firma y la política de fuente de confianza deben configurarse por separado. De lo contrario, un atacante puede fabricar claims falsos.
Extraer solo los campos necesarios en lugar de registrar el cuerpo JSON completo es el enfoque más seguro. Campos como tenant, operation o status pueden registrarse; los campos sensibles deben enmascararse. Esto equilibra la visibilidad del SIEM con la protección de datos.
El enmascaramiento de JSON de respuesta opera sobre el cuerpo, por lo que el tamaño y el tipo de contenido de la respuesta importan. El impacto en rendimiento y memoria sobre respuestas muy grandes debe planificarse. Se requiere una selección correcta de endpoint y campo para aplicar la protección de datos sensibles de forma efectiva.
El análisis JSON y las consultas de path cuestan más que las comprobaciones de cabeceras. Si se usan múltiples consultas JSON dentro de la misma solicitud, la reutilización de resultados es importante. Las reglas deben diseñarse para que no se produzca análisis repetido innecesario.
Una API SaaS puede recibir tráfico de múltiples tenants en un único endpoint. TR7 puede leer el campo `$.tenant_id` y reenviar tráfico al pool de backend correcto para cada tenant.
El valor de rol o scope dentro de un token de Authorization puede leerse. El acceso a rutas de administración puede restringirse a usuarios cuyo token lleve el valor de claim requerido.
Los números de tarjeta, números de identificación o datos de usuario devueltos en una respuesta de API pueden enmascararse. TR7 reduce la exposición de campos sensibles en las respuestas salientes sin requerir cambios en el código de la aplicación.
Cuando un endpoint que espera JSON recibe un cuerpo malformado, TR7 puede rechazar la solicitud anticipadamente. Esto reduce los errores de análisis en la aplicación y reduce la superficie de ataque.
En lugar de registrar el cuerpo completo, solo se extraen campos como `operationName`, `tenant` y `userId`. La correlación SIEM mejora y la minimización de datos se preserva.
JSONQUERY, JWTHEADER y JWTPAYLOAD convierten los campos del cuerpo JSON y los claims JWT en condiciones de regla, entradas de log y acciones de enmascaramiento. Le mostramos una configuración en vivo con sus propios servicios.