La gestion de trafic traditionnelle au niveau de la couche 7 décide généralement sur l'URL, la méthode, les headers et l'adresse source. Ce modèle est souvent suffisant pour les applications web classiques, mais dans les architectures API modernes, la distinction critique réside généralement dans les champs à l'intérieur du corps de la requête. L'identité du tenant, le rôle utilisateur, le type de transaction, le nom de service ou les métadonnées de téléchargement de fichier ne sont pas dans les headers — ils sont dans les payloads JSON, XML, formulaire ou multipart.
Sans cette visibilité, les opérateurs sont poussés vers de mauvaises options. Soit une passerelle API supplémentaire est placée devant la gestion de trafic — ajoutant un nouveau hop, une nouvelle licence et une nouvelle charge opérationnelle — soit l'application elle-même est modifiée pour remonter la valeur de décision dans les headers. Pour les backends legacy et critiques pour l'activité, ce changement n'est souvent pas faisable.
Limiter l'inspection du corps à la seule sécurité ne résout pas non plus le problème. Si le WAAP peut lire le contenu mais que le moteur de routage ne peut pas utiliser la même valeur, la politique de sécurité et la politique de trafic se retrouvent dans deux mondes séparés. Le résultat est une logique dupliquée, des règles incohérentes et un risque d'erreur accru.
Le bon modèle consiste à faire des capacités de parser du corps une partie native du langage de règles. JSONPath, XPath, paramètres de formulaire, JWT claims, regex et vérifications map/liste devraient coexister dans le même arbre d'expression, et une seule expression devrait piloter à la fois une action de trafic et un score WAAP.
Les Règles Content-Aware de TR7 comblent cet écart : les champs à l'intérieur du corps cessent d'être de simples données inspectées et deviennent des signaux qui pilotent directement la décision.
TR7 ne traite pas la conscience du contenu comme un module complémentaire séparé. C'est une partie native du langage de règles de trafic et de sécurité.
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER et JWTPAYLOAD sont des fonctions de premier rang dans le langage de règles. Les opérateurs transforment le contenu du corps en conditions sans écrire de code personnalisé et lient ces conditions directement aux actions de trafic ou de sécurité.
Les payloads JSON, XML et multipart sont analysés à l'exécution et exposés au moteur de règles sous forme de valeurs lisibles. Les opérateurs prennent des décisions sur des champs significatifs plutôt que d'exécuter des regex grossières sur chaque octet de la requête.
Dans TR7, une expression écrite sur un champ du corps peut piloter le routage, la manipulation de headers et le scoring de signature WAAP de la même manière. Ce modèle partagé réduit la logique dupliquée entre les règles de trafic et les règles de sécurité.
En mode ADC, le corps peut être lu et, dans des scénarios appropriés, réécrit côté réponse. En mode WAAP, le corps n'est jamais modifié — il est lu, scoré et bloqué lorsque le seuil de politique est dépassé.
Les Règles Content-Aware transforment les données de payload structurées en conditions lisibles et actions applicables.
La fonction JSONQUERY évalue les champs du corps JSON en utilisant la sémantique JSONPath standard. Les opérateurs peuvent utiliser des valeurs telles que `$.user.role`, `$.items[0].sku` ou `$.tenant_id` comme conditions et les lier au routage vService, à la manipulation de headers ou au scoring WAAP. Le trafic API n'est plus orienté uniquement par endpoint — il est orienté par la signification métier réelle de la requête.
XMLQUERY, XMLPATHTYPE et XMLPATHEXISTS exécutent des requêtes XPath sur les corps XML. Le nom de service, le nœud d'action ou le champ d'opération à l'intérieur d'une enveloppe SOAP peuvent piloter les décisions de routage et de sécurité. Cela est particulièrement précieux pour appliquer un dispatch au niveau du service et une politique sans modifier les backends legacy. Les payloads XML deviennent des données structurées dans le moteur de règles, réduisant la dépendance aux regex fragiles.
La fonction PARAM transforme les query strings, les corps form-encoded et les champs de formulaire en conditions de règle. Le parser multipart expose les métadonnées de téléchargement de fichier — nom de champ, type de contenu et taille — à la politique. Ce pattern est utile pour les portails SaaS, les flux de téléchargement de documents et la logique de transaction spécifique à l'utilisateur. Le trafic peut être routé ou bloqué en fonction du contexte métier que le formulaire porte.
JWTHEADER et JWTPAYLOAD exposent les champs de header et payload du token comme valeurs interrogeables via JSONPath. Le rôle utilisateur, le tenant, le niveau d'autorisation ou les claims personnalisés deviennent des entrées pour les décisions de trafic et de sécurité. Un claim requis peut être appliqué à l'edge, les claims manquants peuvent faire échouer la requête, et le trafic basé sur les rôles peut être orienté vers des groupes backend dédiés — le tout sans intégrer la logique d'accès dans le code applicatif.
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG et MAP_END fournissent des recherches rapides sur de grands ensembles de valeurs. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG et LIST_END offrent le même modèle pour les vérifications basées sur des listes. Les listes de tenants, les noms de service autorisés, les plages IP et les groupes de patterns peuvent être gérés de manière centralisée plutôt que comme des conditions ponctuelles, rendant les grands ensembles de règles maintenables.
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT et XML_NODE_COUNT définissent des limites de protection avant que le parser intervienne. Les payloads surdimensionnés, profondément imbriqués ou gonflés sont rejetés avant d'atteindre le backend. JSON_DEPTH est par défaut à 32 et est réglable au niveau de la politique. Le même contrôle régit à la fois la consommation des ressources et les abus au niveau du parser.
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS et FORM_ALLOWED_ARGS vérifient que les champs attendus sont présents et que les champs inattendus sont absents. Au lieu de seulement rechercher des patterns malveillants, le modèle déclare la forme d'une requête acceptable. Les champs requis manquants ou les paramètres inattendus peuvent être rejetés par politique. Cette approche respectueuse du contrat est particulièrement précieuse sur les endpoints transactionnels critiques.
En mode ADC, l'action modifyResponse applique une substitution basée sur des regex aux corps de réponse. Elle est utilisée pour masquer des données personnelles, réécrire des liens ou adapter des adresses internes pour les consommateurs externes. Le mode WAAP ne modifie jamais le corps — il se contente de lire et de scorer. Cette séparation équilibre la flexibilité du trafic et l'intégrité de sécurité sur la même plateforme.
La conscience du contenu ne se résume pas à la syntaxe des règles — elle couvre aussi la gestion des buffers, la mise en cache des résultats de parsing, la visibilité d'audit et les comportements aux cas limites.
Le contenu du corps est mis en buffer avant le parsing, et le parser JSON, XML ou multipart approprié s'exécute ensuite sur ce buffer. Le buffer de corps par défaut est de 16 Ko ; les paramètres système peuvent être augmentés pour les payloads JSON ou XML plus volumineux. Lorsque la limite est dépassée, la requête est rejetée avec 413 afin de ne pas charger le backend avec des payloads surdimensionnés.
Les résultats JSONPath et XPath lus dans la même requête sont mis en cache dans l'espace de variables à portée de transaction. Une fois qu'une règle a lu un champ du corps, les règles suivantes ne réexécutent pas le parser pour le même champ. Cela réduit la latence et le coût de traitement dans les longues chaînes de règles.
En mode WAAP, le corps est lu mais jamais modifié. Le contenu alimente les signatures, le scoring et la logique de seuil ; une fois le seuil dépassé, la requête est bloquée. La couche de sécurité peut agir sur des signaux content-aware tout en préservant l'intégrité de la requête de bout en bout.
Le parsing des requêtes POST chunked commence après la fin du réassemblage des chunks, de sorte que les champs du corps sont évalués comme un payload complet et cohérent. Le trafic chunked peut engendrer une légère latence supplémentaire, mais le backend est protégé des flux de payload partiels et non contrôlés.
GraphQL est actuellement géré via JSONPath : les champs tels que le nom d'opération et la liste de champs à l'intérieur du corps peuvent être utilisés dans les conditions de règle. Cela permet des décisions pratiques à l'edge telles que la séparation des mutations des requêtes. La validation approfondie du schéma est hors du périmètre de cette capacité.
Quelle règle a lu quel champ du corps est enregistré dans le journal d'audit. Les équipes opérationnelles peuvent tracer pourquoi une requête spécifique a été routée, rejetée ou scorée dans leur SIEM. Cette traçabilité empêche les règles content-aware de se comporter comme une boîte noire.
Les équipes SaaS peuvent dispatcher le trafic vers des pools backend séparés en fonction du champ tenant_id à l'intérieur du corps JSON. La séparation des tenants se fait sans modifier le code applicatif, et la politique de trafic est gérée à l'edge.
Dans les systèmes bancaires et gouvernementaux, le nœud d'action à l'intérieur d'une enveloppe XML peut piloter le dispatch vers différents groupes de services. Le contrat de service legacy reste intact tandis que les décisions de trafic deviennent content-aware.
Les équipes d'ingénierie peuvent orienter les requêtes et les mutations vers des sources séparées en fonction du champ operationName. Les opérations à dominante lecture et celles à dominante écriture atterrissent sur des groupes backend dédiés.
Pour les applications critiques, les claims de rôle et de tenant à l'intérieur du payload JWT peuvent être appliqués à l'edge. Les requêtes auxquelles il manque des claims requis n'atteignent jamais le backend ; les requêtes avec des claims valides sont placées sous la politique de trafic appropriée.
Routage content-aware et sécurité sur les champs JSON, XML, multipart et JWT. Laissez-nous parcourir une mise en place en direct sur vos propres services.