Les backends ne produisent pas toujours des réponses idéales. Les applications legacy peuvent retourner des numéros d'identité, des numéros de carte, des adresses e-mail, des noms d'hôtes internes, des anciens liens ou des informations techniques inutiles. Parce que ces valeurs apparaissent à l'intérieur du corps de réponse plutôt que dans les headers, elles ne peuvent pas être corrigées avec une règle de header standard.
Corriger le problème dans le code applicatif est souvent lent. Le service peut appartenir à une autre équipe, le calendrier de release peut être éloigné de plusieurs mois, ou le code source peut être difficile à modifier en raison d'une technologie vieillissante. Pourtant, l'équipe sécurité et conformité a besoin que la fuite soit fermée immédiatement.
Intervenir dans le corps de réponse sans précaution peut lui-même créer de nouveaux risques. Une regex mal écrite peut corrompre une page entière, l'injection HTML peut atterrir au mauvais endroit, et le traitement de très grandes réponses peut affecter les performances. Les règles de modification du corps doivent donc être appliquées avec des paramètres contrôlés et une portée bien définie.
La bonne approche consiste à gérer les opérations de masquage, remplacement et injection de balises HTML sur le corps de réponse comme des règles de trafic centralisées. Une règle doit savoir à quel chemin, type de contenu ou condition elle s'applique ; le comportement de correspondance et les limites de taille du corps doivent être explicitement définis.
La Modification du Corps de Réponse de TR7 masque, remplace ou injecte du HTML dans le contenu de réponse sans modifier le code backend — résolvant les fuites de données et les besoins de correction legacy au niveau de la couche ADC/WAAP.
TR7 gère la modification du corps de réponse à travers trois modes principaux : le masquage, le remplacement et l'injection de balises HTML.
Le mode mask remplace une portion d'une chaîne ou d'une valeur correspondant à une regex par un caractère de masque. Les paramètres d'offset et de correspondance minimum réduisent le risque de faux positifs.
Le mode replace échange une chaîne spécifique ou une correspondance regex par une nouvelle valeur. Il est utilisé pour corriger les liens legacy, masquer les noms d'hôtes internes ou normaliser de petits problèmes de réponse.
Le mode htmlTag peut insérer des scripts, des bannières, des balises meta ou des fragments HTML similaires dans une réponse — sans toucher au template applicatif.
Les règles de modification du corps peuvent être délimitées à un vService, un chemin, un type de contenu ou une condition de trafic spécifique. La limite de corps par défaut est maintenue basse et peut être augmentée délibérément lorsque nécessaire.
La Modification du Corps de Réponse apporte des changements contrôlés aux corps de réponse à des fins de sécurité, de conformité et de modernisation legacy.
TR7 transforme les changements de contenu en règles centralisées via l'action modifyResponse, qui opère sur le corps de réponse. La règle s'exécute pendant la phase de réponse et traite le corps qui arrive du backend avant d'être transmis au client. Cette structure permet des corrections rapides sans dépendre du code applicatif, des templates ou du processus de release backend — et est particulièrement précieuse pour combler des lacunes de sécurité critiques dans les applications legacy.
Le mode mask remplace une valeur capturée par un caractère de masque choisi. Le caractère de masque est défini comme un seul caractère et prend par défaut la valeur `*`. Un paramètre d'offset permet à un nombre spécifié de caractères au début ou à la fin de rester visibles. Cela protège les données sensibles dans des champs tels que les numéros de carte, les numéros d'identité, les ID de patients ou les adresses e-mail tout en préservant une visibilité partielle.
Le mode replace échange une chaîne spécifique ou une correspondance regex par une nouvelle valeur. Les noms d'hôtes internes, les anciens domaines, les liens incorrects, les endpoints dépréciés ou les détails techniques dans une réponse peuvent tous être corrigés. L'opération normalise la sortie du backend au point de sortie final. Le client reçoit un contenu correct et sécurisé sans aucun changement de code applicatif.
Le mode htmlTag insère des balises ou du contenu spécifiques dans une réponse HTML. Il est utile pour les avis de maintenance, les bannières de sécurité, le texte de conformité ou de petites corrections côté client. L'approche ajoute du contenu au niveau de la réponse sans modifier le template applicatif. Les règles peuvent être délimitées à un chemin ou une condition d'hôte spécifique pour une application contrôlée.
Un matcher de chaîne est disponible pour la correspondance littérale simple. Un matcher regex peut être sélectionné pour des patterns plus complexes. La regex aide à capturer des valeurs variables telles que les numéros d'identité, les formats de carte, les adresses e-mail ou les patterns organisationnels personnalisés. Les opérateurs peuvent choisir une correspondance littérale rapide ou une correspondance flexible basée sur des patterns selon leurs besoins.
La sensibilité à la casse peut être critique dans certains contenus de réponse. TR7 peut contrôler le comportement du matcher avec un paramètre de sensibilité à la casse. Des options telles que les caractères omis permettent de préserver des caractères spécifiques lors du masquage. Cela produit une sortie de masquage plus lisible pour les numéros de téléphone, les IBAN, les numéros de carte ou les valeurs avec un formatage personnalisé.
Le masquage complet n'est pas toujours souhaitable. À des fins d'audit ou d'expérience utilisateur, les quatre derniers chiffres, les premiers caractères ou une section de format spécifique peuvent être laissés visibles. L'offset de masque transforme ce comportement en paramètre de règle. Un standard de masquage partiel est appliqué sans aucun code applicatif.
Certains patterns peuvent produire des correspondances accidentelles uniques. Un paramètre de nombre minimum de correspondances signifie qu'une règle ne s'applique que lorsqu'un nombre spécifié de correspondances est trouvé. Cela aide à éviter qu'un masquage trop agressif ne corrompe une page. Les patterns de données sensibles sont appliqués de manière plus sûre et prévisible.
Le traitement du corps de réponse est plus coûteux que les règles de header. TR7 opère avec une taille de corps limitée par défaut ; cette valeur peut être augmentée lorsque nécessaire. L'impact sur les performances et la mémoire doit être pris en compte pour les très grandes réponses. Les opérateurs doivent exécuter les règles de modification du corps uniquement sur les services et types de contenu où elles sont requises.
La modification du corps peut être appliquée aux réponses d'API JSON, aux pages HTML ou à la sortie en texte brut. Le masquage de champs sensibles en JSON, l'injection de bannières en HTML et le masquage d'informations internes en texte brut sont tous pris en charge. Les règles peuvent être contraintes par des conditions de type de contenu et de chemin. Cette flexibilité permet de gérer différents types d'application avec la même action.
La modification du corps de réponse est l'un des mécanismes d'application côté réponse d'une stratégie de masquage de données sensibles. Lorsque le masquage d'IP dans les journaux, le chiffrement des cookies et le masquage du corps de réponse sont utilisés ensemble, un contrôle plus large de prévention des fuites de données est atteint. Même si le backend retourne plus de données que prévu, TR7 peut intervenir au point de sortie final. Cela donne aux équipes de conformité une couche de sécurité supplémentaire robuste.
Une règle de modification du corps n'a pas besoin de s'exécuter sur chaque réponse. Elle peut être déclenchée par l'hôte, le chemin, le code de statut, le type de contenu, l'utilisateur, l'IP source ou d'autres conditions FX. Cela garantit que la modification n'est appliquée qu'aux endpoints sensibles ou pour des groupes d'utilisateurs spécifiques. Le coût de performance inutile et le risque de substitution non intentionnelle sont tous deux réduits.
La modification du corps de réponse doit être conçue conjointement avec le type de matcher, la taille du corps, la portée du type de contenu, la compression, le comportement de streaming et la visibilité d'audit.
Un matcher de chaîne convient aux correspondances rapides et déterministes. Un matcher regex est plus flexible mais peut correspondre trop largement s'il est mal écrit. Des tests dans une condition de portée étroite sont recommandés pour les règles critiques.
La limite de corps par défaut est maintenue petite et peut être augmentée lorsque nécessaire. Le traitement de grandes réponses crée une surcharge mémoire et de latence. Si la limite doit être augmentée à des centaines de Mo, la portée des endpoints doit être contrainte avec soin.
Les règles doivent être restreintes aux seules réponses JSON, HTML ou texte. La modification du corps ne doit pas être appliquée aux fichiers binaires, archives ou réponses médias. Un filtre de type de contenu est important pour une opération sécurisée.
Si une réponse est compressée, le contenu doit être dans un état traitable avant que la modification du corps puisse s'exécuter. La séquence de compression et de modification doit être planifiée correctement. Sinon le matcher ne verra pas le texte attendu.
La modification du corps sur les réponses en streaming nécessite une gestion plus soigneuse. Les limites de correspondance et le comportement du buffer comptent pour le contenu chunked. La portée de la règle doit être maintenue étroite pour les grands flux ou continus.
Quelle règle s'est exécutée sur quelle réponse peut être journalisée. Au lieu de journaliser la valeur sensible elle-même, des métadonnées telles que le nom de la règle, l'endpoint et le nombre de correspondances doivent être conservées. Cela produit un enregistrement d'audit plus sûr pour la conformité et la revue de sécurité.
Une application financière peut retourner des numéros de carte dans sa réponse. TR7 masque tout sauf les quatre derniers chiffres, réduisant le risque d'exposition de données sensibles.
Une application de santé legacy peut retourner des ID de patients ou des informations d'identité dans sa réponse. TR7 masque ces champs avec un masquage basé sur des regex avant qu'ils n'atteignent l'utilisateur.
Une réponse HTML peut contenir des références à un ancien domaine ou un nom d'hôte interne. Le mode replace substitue ces liens par le nouveau domaine public, facilitant le processus de migration.
Lorsque le template applicatif ne peut pas être modifié, TR7 peut utiliser le mode htmlTag pour ajouter une bannière ou un fragment d'information à la page. Cela fournit une solution pratique pour les avis de maintenance temporaire et de conformité.
Un backend peut retourner des adresses IP internes, des noms d'hôtes ou des informations de version technique dans sa réponse. TR7 supprime ces informations avant qu'elles n'atteignent le client en utilisant une règle de replace ou de mask.
Masquage de données sensibles, réécriture de liens legacy et injection de bannières via les modes mask, replace et htmlTag. Laissez-nous vous présenter une mise en place en direct sur vos propres services.