Les règles de trafic traditionnelles décident généralement sur la base de l'hôte, du chemin, de la méthode et de l'en-tête. Dans le trafic API moderne, cependant, la valeur décisionnelle réelle se trouve généralement à l'intérieur du corps JSON. Le rôle d'un utilisateur, l'identité du locataire, le type de transaction, le montant, le code produit ou le nom d'opération GraphQL peuvent ne pas apparaître du tout dans l'URL.
L'opérateur se retrouve avec deux mauvaises options. Soit une logique de routage et de sécurité supplémentaire est poussée dans le code applicatif, soit l'ADC reste aveugle au niveau de l'en-tête et du chemin. Aucune des deux approches n'est adéquate pour la sécurité API moderne.
Dans les services qui utilisent JWT, le même problème existe à l'intérieur du token. Seule la valeur de l'en-tête Authorization est visible en surface ; le rôle, le groupe, le locataire ou le scope nécessaire pour la décision est stocké dans le payload JWT. Si ces champs ne peuvent pas être lus, la politique de trafic ne peut pas utiliser le contexte d'identité.
Le bon modèle consiste à faire du corps JSON et du contenu JWT une partie native du langage d'expression. Les requêtes JSONPath devraient être utilisables aux côtés des conditions de trafic, des règles de sécurité, de l'enrichissement des logs et des actions de masquage de données — le tout au même endroit.
TR7 Opérations JSON Path fournit ce modèle : JSONQUERY, JWTHEADER et JWTPAYLOAD lient le contenu API aux décisions ADC et WAAP.
TR7 lit le contenu JSON via le moteur d'expressions FX et le porte dans les règles de trafic, les contrôles de sécurité, l'enrichissement des logs et l'édition des réponses.
JSONQUERY cible des champs spécifiques dans le corps de la requête ou de la réponse à l'aide d'une expression JSONPath. Ces champs peuvent ensuite être utilisés comme conditions de trafic, entrées ACL ou valeurs de log.
Les champs d'en-tête et de payload à l'intérieur d'un JWT peuvent être lus en utilisant la même sémantique JSONPath. Le rôle, le scope, le locataire ou l'identité de l'utilisateur peuvent être intégrés dans les décisions de trafic.
Les valeurs à l'intérieur du corps deviennent des conditions aussi naturelles que les vérifications de chemin ou d'en-tête. Des actions peuvent être sélectionnées sur la base de `$.tenant_id`, `$.user.role` ou `$.operationName` comme n'importe quelle autre expression.
Les champs JSON sensibles peuvent être masqués ou substitués côté réponse. La prévention des fuites de données s'applique non seulement dans les logs, mais directement sur le corps retourné au client.
Les Opérations JSON Path connectent le corps JSON et le contenu JWT aux couches de règles, sécurité, logs et masquage de TR7.
JSONQUERY interroge les champs JSON imbriqués directement à l'intérieur du corps. Des expressions telles que `$.user.role`, `$.items[0].sku` ou `$.payment.amount` peuvent être évaluées comme conditions de règle. Les opérateurs peuvent agir sur des données décisionnelles qui n'apparaissent jamais dans l'URL ou les en-têtes. Cela permet de gérer le trafic API selon son contexte de contenu réel.
TR7 peut utiliser un champ lu depuis JSON comme condition d'une règle de trafic. Par exemple, le trafic peut être routé vers différents pools backend selon la valeur `tenant_id`. Si la valeur `role` n'est pas acceptable, la requête peut être rejetée. Une politique de trafic body-aware est établie sans modifier le code applicatif.
La fonction JWTPAYLOAD peut lire les champs de claim à l'intérieur du token. Le rôle utilisateur, le groupe, le scope, le locataire ou l'identité de l'application peuvent être intégrés dans la décision de trafic de cette façon. Cela empêche que l'en-tête Authorization soit traité uniquement comme un token brut. TR7 transforme le contenu du token en signal de politique.
La fonction JWTHEADER peut lire les champs d'en-tête du token. Des vérifications de métadonnées d'algorithme, d'identifiant de clé ou de type de token peuvent être effectuées. Ces informations peuvent être utilisées dans des règles de sécurité, des entrées de logs ou des scénarios d'accès conditionnel. Le token devient un objet auditable, pas simplement une valeur de passage.
Certaines applications transportent des structures de données de type JSON dans des champs d'en-tête personnalisés. TR7 peut traiter ces champs comme des signaux parsables à l'intérieur du moteur d'expressions également. Les données structurées dans les en-têtes — pas seulement dans le corps — font partie de l'évaluation des règles. Cette flexibilité est importante dans les scénarios d'intégration legacy.
Dans les scénarios de passerelle API, des valeurs telles que `operation`, `tenant`, `region` ou `product` à l'intérieur du corps peuvent servir de signaux de routage. TR7 peut acheminer le trafic vers différents pools backend en fonction de ces champs. Cela permet la séparation multi-application ou multi-locataire sous un seul endpoint. La logique de routage n'a pas besoin d'être intégrée dans le code applicatif.
Des champs sélectionnés depuis le corps JSON ou le JWT peuvent être ajoutés aux lignes de log. L'e-mail de l'utilisateur, l'identité du locataire, le type de transaction ou le score de risque peuvent apparaître comme champs dédiés dans le log. Cela renforce la corrélation SIEM. Extraire uniquement les champs requis plutôt que de journaliser le corps complet contribue également à la minimisation des données.
TR7 peut protéger les valeurs sensibles dans le corps JSON de réponse à l'aide d'actions de masquage ou de remplacement. Les numéros de carte, identifiants nationaux, identifiants patient, adresses e-mail ou champs similaires peuvent être ciblés par regex ou par chemin. Cela réduit le risque de fuite de données sans nécessiter de modifications de code de la part de l'équipe applicative. Cela fonctionne en couches avec la capacité de masquage des données sensibles.
Les champs autorisés ou requis à l'intérieur du corps JSON peuvent être liés à une politique de sécurité. Les champs inconnus, les paramètres requis manquants ou les structures excessivement imbriquées peuvent être bloqués. Cela réduit la dérive du schéma API et la surface d'injection. L'inspection du contenu JSON va au-delà des signatures de sécurité négative.
Les payloads JSON profondément imbriqués ou contenant un nombre excessif de clés peuvent épuiser les ressources de l'application et du parser. TR7 peut appliquer des limites telles que la profondeur d'imbrication JSON et le nombre de clés comme politique de sécurité. Cela réduit l'impact des tentatives de DoS sur les API et des structures de corps inattendues. Les limites peuvent être ajustées selon la sensibilité de l'endpoint.
Si le JSON ne peut pas être parsé, la requête n'est pas traitée comme un corps API fiable. TR7 peut rejeter ou journaliser les requêtes avec un JSON mal formé avant de les transmettre au backend. Cela réduit les erreurs de parsing inattendues au niveau de la couche applicative. Cela fournit également une visibilité pour distinguer le trafic d'attaque des clients défaillants.
Un résultat JSONQUERY peut être utilisé conjointement avec des fonctions de chaîne de caractères, regex, map, liste, IP ou hash. Par exemple, une valeur de locataire est extraite depuis JSON, recherchée dans une table de map, et le résultat pilote une décision de routage ou de blocage. Cela fait de la requête JSON une partie du moteur de politique, pas simplement un helper autonome. Les décisions API complexes peuvent être exprimées dans l'éditeur de règles visuel.
Les opérations JSON sont exploitées conjointement avec la mise en tampon du corps, la gestion des erreurs de parsing, le comportement des champs JWT, la minimisation des logs, l'édition des réponses et les limites de performance.
Le corps doit être lisible avant qu'une requête JSON puisse s'exécuter. Les règles body-aware nécessitent donc plus de traitement que les règles header-only. Elles ne doivent être appliquées que sur les endpoints où elles sont réellement nécessaires.
Si le JSON ne peut pas être parsé, la politique peut produire un rejet, une entrée de log ou une action différente. Si un endpoint API attend du JSON, un payload mal formé ne doit pas être transmis au backend. Ce comportement améliore la sécurité de l'endpoint.
Lire le contenu JWT et vérifier le token ne sont pas la même opération. Si les valeurs de claim JWT doivent être utilisées dans les décisions de trafic, la vérification de signature et la politique de source de confiance doivent être configurées séparément. Sans cela, un attaquant peut forger de faux claims.
Extraire uniquement les champs requis plutôt que de journaliser le corps JSON complet est l'approche la plus sécurisée. Des champs tels que tenant, operation ou status peuvent être journalisés ; les champs sensibles doivent être masqués. Cela équilibre la visibilité SIEM avec la protection des données.
Le masquage JSON des réponses opère sur le corps, donc la taille et le type de contenu de la réponse sont importants. L'impact sur les performances et la mémoire pour les très grandes réponses doit être planifié. Un ciblage correct des endpoints et des champs est requis pour appliquer efficacement la protection des données sensibles.
Le parsing JSON et l'interrogation de chemin coûtent plus cher que les vérifications d'en-tête. Si plusieurs requêtes JSON sont utilisées dans la même requête, la réutilisation des résultats est importante. Les règles doivent être conçues pour qu'un parsing répété inutile ne se produise pas.
Une API SaaS peut recevoir du trafic de plusieurs locataires sur un seul endpoint. TR7 peut lire le champ `$.tenant_id` et acheminer le trafic vers le pool backend correct pour chaque locataire.
La valeur de rôle ou de scope à l'intérieur d'un token Authorization peut être lue. L'accès aux chemins admin peut être restreint aux utilisateurs dont le token porte la valeur de claim requise.
Les numéros de carte, numéros d'identité ou données utilisateur retournés dans une réponse API peuvent être masqués. TR7 réduit l'exposition des champs sensibles dans les réponses sortantes sans nécessiter de modifications du code applicatif.
Lorsqu'un endpoint attendant du JSON reçoit un corps mal formé, TR7 peut rejeter la requête en amont. Cela réduit les erreurs de parsing applicatif et réduit la surface d'attaque.
Plutôt que de journaliser le corps complet, seuls des champs tels que `operationName`, `tenant` et `userId` sont extraits. La corrélation SIEM s'améliore et la minimisation des données est préservée.
JSONQUERY, JWTHEADER et JWTPAYLOAD transforment les champs du corps JSON et les claims JWT en conditions de règle, entrées de logs et actions de masquage. Parcourons ensemble une configuration en direct sur vos propres services.