Im REST-Traffic beschreiben Endpoint, Methode und Pfad üblicherweise, was ein Request tut. In GraphQL lebt diese Information meist im Body. Derselbe `/graphql`-Endpoint kann Lesevorgänge, Schreibvorgänge, verschachtelte Queries, Introspection, Fragmente und variablengesteuerte Operationen tragen. Eine Sicherheitsschicht, die nur URL und Methode prüft, kann nicht sehen, was GraphQL tatsächlich tut.
Wenn GraphQL-Introspection in der Produktion offen bleibt, kann das Anwendungsschema leaken. Ein Angreifer, der erfährt, welche Typen, Felder und Beziehungen existieren, kann weit zielgerichtetere Queries erstellen. Das ist keine direkte Datenexfiltration, aber eine ernsthafte Informationsoffenbarung, die die Angriffsfläche kartiert.
Verschachtelte Queries und Fragmente erzeugen ein anderes Risiko. Übermäßig tief verschachtelte Queries können mit einem einzigen HTTP-Request eine hohe Verarbeitungslast auf dem Backend erzeugen. Standard-Rate-Limiting zählt Requests — es sieht nicht den Aufwand eines einzelnen Requests. In GraphQL kommt das DoS-Risiko üblicherweise aus der Query-Struktur, nicht dem Request-Volumen.
Query-Batching erzeugt eine ähnliche Lücke. Wenn mehrere Queries in einem Body gesendet werden, sieht der Traffic von außen wie ein einzelner HTTP-Request aus, aber intern können mehrere Operationen ausgeführt werden. Das untergräbt klassische Rate-Limit- und endpoint-basierte Sicherheitskontrollen.
TR7 GraphQL Deep Inspection untersucht GraphQL-Traffic mit musterbasierten WAAP-Regeln: Introspection-, verschachtelte-Tiefen-DoS- und Query-Batching-Verhalten werden über Query-, Raw-, JSON- und Formularbereiche erkannt und mit Produktionspolicies verknüpft.
TR7 adressiert GraphQL-Sicherheit nicht durch Schema-Bewusstsein, sondern indem die häufigsten Produktions-GraphQL-Missbrauchsmuster in die WAAP-Signatur-Engine gebracht werden.
TR7 erkennt Introspection-Indikatoren wie `__schema`, `__type`, `IntrospectionQuery` und `fragment FullType` mit regex-basierten Regeln. Diese Regeln können im Block-Modus in der Produktion und im Monitor-Modus oder mit einem niedrigeren Score in Staging laufen.
Übermäßig verschachtelte GraphQL-Queries können mit einem einzelnen Request hohe Verarbeitungslast erzeugen. Die TR7-50101-Regelfamilie erkennt tiefe `{ ... { ... } }`-Ketten auf Musterebene und bezieht sie mit einem hohen Score in die WAAP-Entscheidung ein.
Das Senden mehrerer Queries in einem Body kann klassische Rate-Limit-Logik untergraben. TR7-Regel 50102 erkennt Batch-Query-Muster und ermöglicht es, dieses Verhalten mit einer Log-, Score- oder Block-Entscheidung zu verknüpfen.
Eine GraphQL-Query kann nicht nur im rohen Body, sondern auch in JSON-, Formular- oder Query-String-Feldern übertragen werden. TR7-Regeln laufen über Query-, Raw-, JSON- und Formularbereiche und bringen verschiedene Client-Implementierungen unter dieselbe WAAP-Policy.
GraphQL Deep Inspection verwaltet GraphQL-spezifische Risiken mit signaturbasierten WAAP-Regeln, Bereichsauswahl und Endpoint-Härtungskontrollen.
Regel 50100 zielt auf Muster ab, die häufig bei GraphQL-Introspection verwendet werden: `__schema`, `__type`, `IntrospectionQuery` und `fragment FullType`. Das Standard-Risikoniveau ist als mittleres Signal positioniert und kann bei Score 4 ausgewertet werden. Auf Endpoints, wo Introspection in der Produktion geschlossen sein muss, kann diese Regel im Block- oder Monitor-Modus laufen. Schema-Discovery-Versuche werden im WAAP-Event-Stream sichtbar.
Regel 50101 erkennt übermäßig verschachtelte GraphQL-Queries auf Musterebene. Tiefe `{`-Ketten und stark verschachtelte Strukturen können dazu führen, dass ein einzelner Request hohe Verarbeitungskosten auf dem Backend verursacht. Diese Regel kann bei Score 6 als stärkeres Angriffssignal ausgewertet werden. Das Ziel ist nicht, schema-bewusste Komplexitätsberechnung durchzuführen — es ist, gefährliche verschachtelte Query-Muster frühzeitig zu erkennen.
Regel 50102 erkennt Batch-Muster, bei denen mehrere Queries in einem einzigen Body gesendet werden. Da Query-Batching für einige Clients legitim sein kann, sollten Status- und Score-Werte der Regel auf das Verhalten der Anwendung abgestimmt werden. Im Monitor-Modus zu starten und mit echter Verkehrsbeobachtung zu klären ist der richtige Ansatz. Sobald Missbrauch bestätigt ist, kann die Regel zu einer Block-Policy verschoben werden.
Neben TR7-erweiterten Regeln enthält waf_db GraphQL-Varianten wie die 50100-, 50101- und 21360+-Familien. Diese Varianten decken alternative Schreibweisen wie `__schema {`, `__type`, `__typename` und verschachtelte Mutations-Muster ab. Dies schafft eine breitere Signaturoberfläche für Introspection- und verschachtelte Query-Verhalten, ohne auf eine einzige Regex angewiesen zu sein. Operatoren können Status und Score dieser Regeln pro Service überschreiben.
GraphQL-Queries kommen nicht immer im gleichen Format an. Einige Clients senden `query`, `variables` und `operationName`-Felder in einem JSON-Body; andere können rohen Body oder Formularfelder verwenden. TR7-Regeln laufen über Query-, Raw-, JSON- und Formularbereiche und bringen diese verschiedenen Transportformate unter die Inspektionsabdeckung. Dies reduziert den Fehler, auf GraphQL-Endpoints nur einem Body-Format zu vertrauen.
GraphQL-Kontrollen können sowohl auf api_endpoint- als auch auf web_application-Ziele angewendet werden. Dasselbe WAAP-Regelmodell kann mit verschiedenen Status-, Score- oder Bereichswerten je nach Service-Typ verwaltet werden. Beispielsweise kann Introspection auf einem internen Test-Endpoint im Monitor-Modus bleiben, während sie auf einem öffentlichen Produktions-Endpoint blockiert wird. Diese Flexibilität ermöglicht die Anpassung eines einzigen Regelsatzes an verschiedene Umgebungspolicies.
Für den `/graphql`-Endpoint können Kontrollen definiert werden, z. B. nur die POST-Methode zuzulassen, erwartete JSON-Keys auf `query`, `variables` und `operationName` zu beschränken oder ein Body-Größenlimit anzuwenden. Diese Kontrollen ersetzen keine GraphQL-Signaturen — sie sind eine positive Sicherheitsschicht, die sie ergänzt. Unerwartete Methoden oder JSON-Felder können in einem frühen Stadium abgelehnt werden, was das Endpoint-Verhalten vorhersehbarer macht.
Wenn GraphQL-Traffic anwendungsspezifische Mutations-Muster, Feldnamen oder riskante Operationsnamen enthält, können diese als benutzerdefinierte WAAP-Regeln hinzugefügt werden. Beispielsweise kann ein bestimmtes `mutation`-Schlüsselwort oder ein sensibler Operationsname im Body mit einem höheren Score versehen werden. Diese benutzerdefinierten Regeln nehmen am WAAP-Hauptbewertungssystem teil und sind im Log- und SIEM-Stream sichtbar. Auch ohne schema-bewusste Feldinspektion können anwendungsspezifische Risiken mit musterbasierten Regeln erkannt werden.
GraphQL Deep Inspection ist in seinen aktuellen realen Fähigkeiten signaturbasiert — Operations-Parsing, Komplexitätsberechnung und schema-bewusste Feld-WAAP-Ansprüche liegen außerhalb des Umfangs dieser Seite.
GraphQL-Kontrollen arbeiten mit einem regex- und bereichsbasierten Mustererkennungsansatz. Operationstyp-Differenzierung, ein echter Tiefenzähler oder Query-Komplexitäts-Score-Berechnung sind kein Teil dieses Modells. Diese Unterscheidung ist besonders wichtig für genaue Positionierung.
Regeln 50100, 50101, 50102 und waf_db-Varianten können je nach Service-Bedarf auf aktiviert, Monitor oder deaktiviert gesetzt werden. Score-Werte können ebenfalls auf die False-Positive-Toleranz der Anwendung abgestimmt werden. Das richtige Rollout-Modell für Produktions-GraphQL-Endpoints ist, im Monitor-Modus zu starten und nach echter Verkehrsbeobachtung zur Blockierung zu wechseln.
Methoden-Whitelist, JSON-Key-Allow-List und Body-Größenlimit können auf GraphQL-Endpoints angewendet werden. Diese Kontrollen stellen sicher, dass die Request-Form neben der Signaturerkennung dem erwarteten Vertrag entspricht. Besonders auf öffentlichen APIs verringert das Akzeptieren nur des erwarteten Formats auf dem `/graphql`-Endpoint die Angriffsfläche.
Operationsbasiertes Rate-Limiting wird nicht auf GraphQL-Parser-Ebene angewendet. Es gibt keinen Anspruch, die Anzahl der Operationen innerhalb eines einzelnen Bodys semantisch zu parsen und jeder ein separates Limit zu geben. Das Query-Batching-Muster kann als Signatur erkannt und zusammen mit allgemeinen Rate-Limit-Policies verwendet werden.
Es gibt keine dedizierte Unterstützung für persistierte Queries innerhalb dieser Fähigkeit. GraphQL-Muster, die im Request sichtbar sind, werden mit WAAP-Signaturen inspiziert. Eine Query aus ihrem Hash aufzulösen und gegen Schema- oder registrierte Operationsdaten zu verifizieren wird auf dieser Seite nicht beansprucht.
Native Inspektion auf der Ebene eines spezifischen GraphQL-Schema-Felds — beispielsweise `User.email` — wird nicht durchgeführt. Regeln arbeiten mit einem Musterabgleich-Ansatz gegen den Body. Wenn es feldspezifische Anforderungen gibt, sollten diese begrenzt und sorgfältig mit einer benutzerdefinierten Regex-Regel adressiert werden.
Ein Sicherheitsteam kann Introspection im Staging erlauben, während Regel 50100 auf dem Produktions-Endpoint im Block-Modus läuft. Schema-Discovery-Versuche werden geloggt, bewertet und per Policy blockiert.
Übermäßig verschachtelte Fragmente oder Query-Strukturen können hohe Verarbeitungskosten auf dem Backend verursachen. Regel 50101 erkennt diese Muster bei Score 6 und liefert ein starkes Signal für die WAAP-Blockierungsentscheidung.
Wenn viele Queries in einem einzigen Request an einen mobilen Client-Endpoint versucht werden, erkennt Regel 50102 das Batch-Muster. Das Operations-Team kann das Verhalten zuerst im Monitor-Modus beobachten und in den aktivierten Modus wechseln, sobald Missbrauch bestätigt ist.
Ein API-Team kann auf dem `/graphql`-Endpoint nur die POST-Methode und die JSON-Felder `query`, `variables` und `operationName` erlauben. Unerwartete Methoden oder Felder werden abgelehnt, bevor sie die Anwendung erreichen, und das Endpoint-Verhalten wird eingeschränkt.
Introspection-, verschachtelte DoS- und Query-Batching-Risiken in der Produktion sichtbar und handhabbar machen. Wir zeigen Ihnen ein Live-Setup auf Ihren eigenen Diensten.