Moderne API-Entscheidungen werden im JSON-Body getroffen — nicht in der URL.
Traditionelle Traffic-Regeln entscheiden typischerweise basierend auf Host, Pfad, Methode und Header. In modernem API-Traffic liegt der eigentliche Entscheidungswert jedoch meist im JSON-Body. Die Rolle eines Benutzers, die Tenant-Identität, der Transaktionstyp, der Betrag, der Produktcode oder der GraphQL-Operationsname erscheinen möglicherweise überhaupt nicht in der URL.
Dies lässt dem Operator zwei schlechte Optionen. Entweder wird zusätzliche Routing- und Sicherheitslogik in den Anwendungscode verlagert, oder der ADC bleibt blind auf Header- und Pfadebene. Keiner dieser Ansätze ist für moderne API-Sicherheit angemessen.
In Services, die JWT verwenden, besteht dasselbe Problem im Token. Nur der Authorization-Header-Wert ist an der Oberfläche sichtbar; die für die Entscheidung benötigte Rolle, Gruppe, Tenant oder Scope ist im JWT-Payload gespeichert. Wenn diese Felder nicht gelesen werden können, kann die Traffic-Richtlinie keinen Identitätskontext verwenden.
Das richtige Modell besteht darin, den JSON-Body und JWT-Inhalt zu einem nativen Bestandteil der Ausdruckssprache zu machen. JSONPath-Abfragen sollten neben Traffic-Bedingungen, Sicherheitsregeln, Log-Anreicherung und Datenmaskierungsaktionen verwendbar sein — alles an derselben Stelle.
TR7 JSON-Path-Operationen liefert dieses Modell: JSONQUERY, JWTHEADER und JWTPAYLOAD binden API-Inhalt an ADC- und WAAP-Entscheidungen.
Unser Ansatz
TR7 liest JSON-Inhalt über die FX-Ausdrucks-Engine und trägt ihn in Traffic-Regeln, Sicherheitskontrollen, Log-Anreicherung und Antwortbearbeitung ein.
JSONQUERY liest Felder direkt aus dem Body
JSONQUERY zielt auf bestimmte Felder im Anfrage- oder Antwort-Body mit einem JSONPath-Ausdruck ab. Diese Felder können dann als Traffic-Bedingungen, ACL-Eingaben oder Log-Werte verwendet werden.
JWTHEADER und JWTPAYLOAD machen Token-Inhalt sichtbar
Header- und Payload-Felder in einem JWT können mit derselben JSONPath-Semantik gelesen werden. Rolle, Scope, Tenant oder Benutzeridentität können in Traffic-Entscheidungen eingebracht werden.
JSON-Felder werden zu Regelbedingungen
Werte im Body werden zu Bedingungen so natürlich wie Pfad- oder Header-Prüfungen. Aktionen können basierend auf `$.tenant_id`, `$.user.role` oder `$.operationName` genauso wie jeder andere Ausdruck ausgewählt werden.
JSON-Antwortfelder können maskiert oder ersetzt werden
Sensible JSON-Felder können auf der Antwortseite maskiert oder ersetzt werden. Data-Leak-Prevention wird nicht nur in Logs, sondern direkt am an den Client zurückgegebenen Body angewendet.
Fähigkeiten
JSON-Path-Operationen verbindet JSON-Body und JWT-Inhalt mit den Regel-, Sicherheits-, Log- und Maskierungsschichten von TR7.
JSONQUERY zielt auf verschachtelte Felder mit JSONPath
JSONQUERY fragt direkt verschachtelte JSON-Felder im Body ab. Ausdrücke wie `$.user.role`, `$.items[0].sku` oder `$.payment.amount` können als Regelbedingungen ausgewertet werden. Operatoren können auf Entscheidungsdaten reagieren, die nie in der URL oder in Headern auftauchen. Dies ermöglicht es, API-Traffic nach seinem tatsächlichen Inhaltskontext zu verwalten.
JSON-Felder binden sich direkt an ACL-Bedingungen
TR7 kann ein aus JSON gelesenes Feld als Bedingung einer Traffic-Regel verwenden. Beispielsweise kann Traffic basierend auf dem `tenant_id`-Wert an verschiedene Backend-Pools geroutet werden. Wenn der `role`-Wert nicht akzeptabel ist, kann die Anfrage abgelehnt werden. Body-bewusste Traffic-Policy wird ohne Modifikation des Anwendungscodes etabliert.
JWT-Payload-Inhalt signalisiert Zugriffsentscheidungen
Die JWTPAYLOAD-Funktion kann Claim-Felder im Token lesen. Benutzerrolle, Gruppe, Scope, Tenant oder Anwendungsidentität können so in die Traffic-Entscheidung einbezogen werden. Dies verhindert, dass der Authorization-Header nur als roher Token behandelt wird. TR7 wandelt Token-Inhalt in ein Policy-Signal um.
JWT-Header-Abfrage ermöglicht Algorithmus- und Token-Metadaten-Prüfungen
Die JWTHEADER-Funktion kann Token-Header-Felder lesen. Algorithmus-, Key-ID- oder Token-Typ-Metadaten-Prüfungen können durchgeführt werden. Diese Informationen können in Sicherheitsregeln, Log-Einträgen oder Szenarien mit bedingtem Zugriff verwendet werden. Der Token wird zu einem prüfbaren Objekt, nicht nur zu einem Durchgangswert.
In Headern enthaltene JSON-Werte können geparst werden
Einige Anwendungen tragen JSON-ähnliche Datenstrukturen in benutzerdefinierten Header-Feldern. TR7 kann diese Felder auch innerhalb der Ausdrucks-Engine als parseable Signale behandeln. Strukturierte Daten in Headern — nicht nur im Body — werden Teil der Regelauswertung. Diese Flexibilität ist wichtig in Legacy-Integrationsszenarien.
Backend-Auswahl kann durch JSON-Feldwerte gesteuert werden
In API-Gateway-Szenarien können Werte wie `operation`, `tenant`, `region` oder `product` im Body als Routing-Signale dienen. TR7 kann Traffic basierend auf diesen Feldern an verschiedene Backend-Pools weiterleiten. Dies ermöglicht Multi-Anwendungs- oder Multi-Tenant-Trennung unter einem einzigen Endpunkt. Routing-Logik muss nicht in den Anwendungscode eingebettet werden.
JSON-Felder können Log-Einträge anreichern
Ausgewählte Felder aus dem JSON-Body oder JWT können zu Log-Zeilen hinzugefügt werden. Benutzer-E-Mail, Tenant-Identität, Transaktionstyp oder Risikoscore können als dedizierte Felder im Log erscheinen. Dies stärkt die SIEM-Korrelation. Das Extrahieren nur der benötigten Felder statt des vollständigen Body-Loggings unterstützt auch die Datenminimerung.
Sensible Felder in Antwort-JSON können maskiert werden
TR7 kann sensible Werte im JSON-Antwort-Body mit Maskierungs- oder Ersetzungsaktionen schützen. Kartennummern, nationale IDs, Patienten-IDs, E-Mail-Adressen oder ähnliche Felder können per Regex oder Pfad gezielt angesprochen werden. Dies reduziert das Datenleck-Risiko ohne Code-Änderungen vom Anwendungsteam zu erfordern. Es arbeitet schichtweise neben der Fähigkeit zur Maskierung sensibler Daten.
WAAP-Positivsicherheitsregeln können JSON-Schlüssel einschränken
Erlaubte oder erforderliche Felder im JSON-Body können an eine Sicherheitsrichtlinie gebunden werden. Unbekannte Felder, fehlende erforderliche Parameter oder übermäßig verschachtelte Strukturen können blockiert werden. Dies reduziert API-Schema-Drift und die Injection-Angriffsfläche. JSON-Inhaltsinspektion geht über negative Sicherheitssignaturen hinaus.
JSON-Tiefe und Schlüsselanzahl-Limits verbessern Parser-Sicherheit
Tief verschachtelte oder übermäßig viele Schlüssel enthaltende JSON-Payloads können Anwendungs- und Parser-Ressourcen erschöpfen. TR7 kann Limits wie JSON-Verschachtelungstiefe und Schlüsselanzahl als Sicherheitsrichtlinie durchsetzen. Dies reduziert die Auswirkung von API-DoS-Versuchen und unerwarteten Body-Strukturen. Limits können pro Endpunkt-Sensitivität angepasst werden.
Fehlerhafte JSON-Anfragen können abgelehnt werden, bevor sie das Backend erreichen
Wenn JSON nicht geparst werden kann, wird die Anfrage nicht als vertrauenswürdiger API-Body behandelt. TR7 kann Anfragen mit fehlerhaftem JSON ablehnen oder loggen, bevor sie an das Backend weitergeleitet werden. Dies reduziert unerwartete Parse-Fehler auf der Anwendungsebene. Es bietet auch Sichtbarkeit zur Unterscheidung zwischen Angriffstraffic und fehlerhaften Clients.
JSON-Abfragen kombinieren sich mit anderen FX-Funktionen
Ein JSONQUERY-Ergebnis kann zusammen mit String-, Regex-, Map-, Listen-, IP- oder Hash-Funktionen verwendet werden. Beispielsweise wird ein Tenant-Wert aus JSON extrahiert, in einer Map-Tabelle nachgeschlagen, und das Ergebnis steuert eine Routing- oder Block-Entscheidung. Dies macht die JSON-Abfrage zu einem Teil der Policy-Engine, nicht nur zu einem eigenständigen Helfer. Komplexe API-Entscheidungen können im visuellen Regel-Editor ausgedrückt werden.
Operative Tiefe
JSON-Operationen werden zusammen mit Body-Pufferung, Parse-Fehlerbehandlung, JWT-Feldverhalten, Log-Minimierung, Antwortbearbeitung und Leistungslimits betrieben.
Zeitpunkt des Body-Zugriffs
Der Body muss lesbar sein, bevor eine JSON-Abfrage ausgeführt werden kann. Body-bewusste Regeln erfordern daher mehr Verarbeitung als Header-Only-Regeln. Sie sollten nur auf Endpunkten angewendet werden, wo sie tatsächlich benötigt werden.
Parse-Fehlerverhalten
Wenn JSON nicht geparst werden kann, kann die Policy eine Ablehnung, einen Log-Eintrag oder eine andere Aktion erzeugen. Wenn ein API-Endpunkt JSON erwartet, sollte ein fehlerhafter Payload nicht an das Backend weitergeleitet werden. Dieses Verhalten verbessert die Endpunktsicherheit.
JWT-Vertrauensannahme
JWT-Inhalt lesen und den Token verifizieren sind nicht dieselbe Operation. Wenn JWT-Claim-Werte in Traffic-Entscheidungen verwendet werden sollen, muss die Signaturverifizierung und Trust-Source-Policy separat konfiguriert werden. Andernfalls kann ein Angreifer falsche Claims erstellen.
Log-Minimierung
Nur die erforderlichen Felder statt des vollständigen JSON-Body zu loggen ist der sicherere Ansatz. Felder wie Tenant, Operation oder Status können geloggt werden; sensible Felder sollten maskiert werden. Dies balanciert SIEM-Sichtbarkeit mit Datenschutz.
Einschränkungen bei der Antwortbearbeitung
JSON-Maskierung von Antworten arbeitet am Body, daher sind Antwortgröße und Content-Type wichtig. Leistungs- und Speicherauswirkungen bei sehr großen Antworten sollten geplant werden. Korrektes Targeting von Endpunkten und Feldern ist erforderlich, um sensiblen Datenschutz effektiv anzuwenden.
Leistungsauswirkung
JSON-Parsing und Pfad-Abfragen kosten mehr als Header-Prüfungen. Wenn mehrere JSON-Abfragen innerhalb derselben Anfrage verwendet werden, ist die Wiederverwendung von Ergebnissen wichtig. Regeln sollten so gestaltet sein, dass unnötiges wiederholtes Parsing nicht auftritt.
Wann es verwendet wird
An Backend per Tenant-ID-Wert routen
Eine SaaS-API kann Traffic von mehreren Tenants auf einem einzelnen Endpunkt empfangen. TR7 kann das `$.tenant_id`-Feld lesen und Traffic für jeden Tenant an den richtigen Backend-Pool weiterleiten.
Zugriffskontrolle auf JWT-Rollen-Claims durchsetzen
Der Rollen- oder Scope-Wert innerhalb eines Authorization-Tokens kann gelesen werden. Der Zugriff auf Admin-Pfade kann auf Benutzer beschränkt werden, deren Token den erforderlichen Claim-Wert trägt.
Sensible Felder in Antwort-JSON maskieren
Kartennummern, Identitätsnummern oder in einer API-Antwort zurückgegebene Benutzerdaten können maskiert werden. TR7 reduziert die Exposition sensibler Felder in ausgehenden Antworten ohne Code-Änderungen in der Anwendung zu erfordern.
Fehlerhaftes JSON ablehnen, bevor es das Backend erreicht
Wenn ein JSON-erwartender Endpunkt einen fehlerhaften Body erhält, kann TR7 die Anfrage frühzeitig ablehnen. Dies reduziert Anwendungs-Parse-Fehler und verkleinert die Angriffsfläche.
Log-Zeilen mit Betriebs- und Tenant-Daten anreichern
Statt den vollständigen Body zu loggen, werden nur Felder wie `operationName`, `tenant` und `userId` extrahiert. SIEM-Korrelation verbessert sich und Datenminimerung wird gewahrt.
Häufig gestellte Fragen
Welche JSONPath-Syntax unterstützt JSONQUERY?
Wird beim Lesen von JWT-Inhalt automatisch eine Signaturverifizierung durchgeführt?
Wie hält die Leistung stand, wenn mehrere JSON-Felder in derselben Anfrage gelesen werden?
Wird JSON-Maskierung nur auf der Antwortseite angewendet?
Was macht TR7, wenn es einen fehlerhaften JSON-Body erhält?
Wie hängt diese Fähigkeit mit der Seite zur Maskierung sensibler Daten zusammen?
API-Body-Inhalt zu einem Teil Ihrer Traffic- und Sicherheitsentscheidungen machen
JSONQUERY, JWTHEADER und JWTPAYLOAD wandeln JSON-Body-Felder und JWT-Claims in Regelbedingungen, Log-Einträge und Maskierungsaktionen um. Lassen Sie uns eine Live-Einrichtung auf Ihren eigenen Services durchführen.