Las decisiones modernas de API se toman dentro del cuerpo JSON — no en la URL.
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.
Nuestro enfoque
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 lee campos directamente del cuerpo
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.
JWTHEADER y JWTPAYLOAD hacen visible el contenido del token
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 campos JSON se convierten en condiciones de regla
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 de respuesta pueden enmascararse o sustituirse
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.
Capacidades
Operaciones JSON Path conecta el cuerpo JSON y el contenido JWT a las capas de reglas, seguridad, log y enmascaramiento de TR7.
JSONQUERY apunta a campos anidados con JSONPath
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.
Los campos JSON se vinculan directamente a condiciones ACL
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.
El contenido del payload JWT señaliza decisiones de acceso
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 consulta de la cabecera JWT proporciona comprobaciones de algoritmo y metadatos del token
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.
Los valores JSON transportados en cabeceras pueden analizarse
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.
La selección de backend puede impulsarse por valores de campo JSON
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.
Los campos JSON pueden enriquecer las entradas de log
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.
Los campos sensibles en el JSON de respuesta pueden enmascararse
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.
Las reglas de seguridad positiva WAAP pueden restringir las claves JSON
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 límites de profundidad y recuento de claves JSON mejoran la seguridad del parser
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.
Las solicitudes JSON malformadas pueden rechazarse antes de llegar al backend
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.
Las consultas JSON se componen con otras funciones FX
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.
Profundidad operacional
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.
Momento de acceso al cuerpo
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.
Comportamiento ante errores de análisis
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.
Suposición de confianza en JWT
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.
Minimización de logs
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.
Límites de edición de respuestas
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.
Impacto en el rendimiento
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.
Cuándo utilizarlo
Enrutar al backend por valor de tenant ID
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.
Aplicar control de acceso sobre claims de rol JWT
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.
Enmascarar campos sensibles en JSON de respuesta
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.
Rechazar JSON malformado antes de que llegue al backend
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.
Enriquecer líneas de log con datos de operación y tenant
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.
Preguntas frecuentes
¿Qué sintaxis JSONPath soporta JSONQUERY?
¿Se realiza automáticamente la verificación de firma al leer el contenido JWT?
¿Cómo se mantiene el rendimiento cuando se leen múltiples campos JSON en la misma solicitud?
¿El enmascaramiento JSON se aplica solo en el lado de la respuesta?
¿Qué hace TR7 cuando recibe un cuerpo JSON malformado?
¿Cómo se relaciona esta capacidad con la página de enmascaramiento de datos sensibles?
Haga del contenido del cuerpo de la API parte de sus decisiones de tráfico y seguridad
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.