GraphQL trägt zu viel Funktionalität über einen einzigen Endpoint — klassische WAAP-Logik übersieht das meiste davon.
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.
Unser Ansatz
TR7 adressiert GraphQL-Sicherheit nicht durch Schema-Bewusstsein, sondern indem die häufigsten Produktions-GraphQL-Missbrauchsmuster in die WAAP-Signatur-Engine gebracht werden.
Introspection-Muster können in der Produktion blockiert 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.
Verschachtelte Query-DoS-Muster werden bewertet und erkannt
Ü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.
Query-Batching-Verhalten wird unter einem einzelnen Request sichtbar
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.
Body-Bereich-Inspektion sucht nach GraphQL-Payloads an mehreren Stellen
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.
Fähigkeiten
GraphQL Deep Inspection verwaltet GraphQL-spezifische Risiken mit signaturbasierten WAAP-Regeln, Bereichsauswahl und Endpoint-Härtungskontrollen.
TR7-Regel 50100 erkennt GraphQL-Introspection-Versuche
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.
TR7-Regel 50101 fokussiert sich auf verschachtelte Query-DoS-Muster
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.
TR7-Regel 50102 erkennt Query-Batching-Missbrauch
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.
waf_db-GraphQL-Varianten erweitern Introspection- und verschachtelte Muster-Abdeckung
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.
Query-, Raw-, JSON- und Formularbereiche decken verschiedene Transportformate ab
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.
Dasselbe Regelmodell gilt für API-Endpoint- und Web-Anwendungs-Ziele
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.
StructureRuleDB kann GraphQL-Endpoint-Verhalten einschränken
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.
Benutzerdefinierte Regeln können anwendungsspezifische GraphQL-Muster hinzufügen
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.
Operative Tiefe
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.
Musterbasierte Inspektion
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.
Status- und Score-Überschreibung
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.
Endpoint-Härtung
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.
Rate-Limit-Grenze
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.
Persistierter Query-Bereich
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.
Nicht-schema-bewusstes Modell
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.
Wann es einzusetzen ist
Introspection auf einem Produktions-GraphQL-Endpoint blockieren
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.
Verschachtelte Fragment-DoS-Versuche mit Scoring blockieren
Ü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.
Einen Query-Batching-Angriff auf einer mobilen API erkennen
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.
Methoden- und JSON-Key-Whitelist für einen GraphQL-Endpoint
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.
Häufig gestellte Fragen
Ist die TR7-GraphQL-Unterstützung ein nativer Parser oder musterbasiert?
Kann ich Introspection in der Produktion vollständig schließen?
Verursacht die Query-Batching-Erkennung Probleme für legitime Nutzung?
Über welche Bereiche laufen GraphQL-Regeln?
Was ist der Unterschied zwischen waf_db-Varianten und erweiterten Regeln?
Wie wird die GraphQL-Endpoint-Härtung mit StructureRuleDB durchgeführt?
Ihre GraphQL-Endpoints mit der WAAP-Signatur-Engine verbinden
Introspection-, verschachtelte DoS- und Query-Batching-Risiken in der Produktion sichtbar und handhabbar machen. Wir zeigen Ihnen ein Live-Setup auf Ihren eigenen Diensten.