Federated Sub-graph Injection: Der "Blinde" GraphQL-Datenleck

Als Unternehmen sich aggressiv von monolithischen Architekturen zu Federated GraphQL (Supergraphs) bewegen, ist eine neue und kritische Schwachstellenklasse aufgetaucht: Federated Sub-graph Injection. Während Organisationen ihre API-Gateways absichern, vernachlässigen sie oft die weiche Unterseite der Architektur — die Sub-graphs selbst. Diese Schwachstelle nutzt das implizite Vertrauen zwischen dem Gateway und seinen Sub-graphs aus, wodurch Angreifer sensible Datenfragmente aus privaten Microservices “zusammensticken” können, die niemals verbunden werden sollten. Dieser Artikel erklärt die Mechanismen des Angriffs, warum er für traditionelle WAFs unsichtbar ist und wie man eine Zero Trust-Architektur für den Data Graph implementiert.

---

Der Aufstieg des Supergraphen (und die Sicherheitslücke)

Im modernen API-Umfeld hat sich GraphQL Federation — populär gemacht durch Apollo Federation, Hasura und WunderGraph — zum Goldstandard entwickelt, um Dutzende disparate Microservices (Sub-graphs) in einen einzigen, abfragbaren Endpunkt (den Supergraph oder Gateway) zu vereinen.

Die Architektur des Vertrauens

In einer typischen federated Konfiguration:

1. Der Nutzer sendet eine Anfrage an das Gateway.
2. Das Gateway validiert das JWT des Nutzers, prüft hochstufige Berechtigungen und erstellt einen Query-Plan.
3. Das Gateway teilt die Anfrage in Fragmente auf und sendet sie an die jeweiligen Sub-graphs (z.B. Users Service, Billing Service, Inventory Service).
4. Die Sub-graphs führen ihre Teile aus und liefern JSON zurück.
5. Das Gateway verbindet (“stitcht”) die Ergebnisse und sendet sie an den Nutzer.

Der fatale Fehler: Die meisten Entwicklerteams behandeln Sub-graphs als “intern” und daher “sicher”. Sie gehen davon aus, dass, wenn eine Anfrage einen Sub-graph erreicht, das Gateway diese bereits autorisiert hat. Folglich entfernen Sub-graphs oft ihre eigenen Autorisierungsprüfungen, was ein klassisches Confused Deputy-Problem schafft.

---

Was ist Federated Sub-graph Injection?

Federated Sub-graph Injection ist eine serverseitige Schwachstelle, bei der ein Angreifer die GraphQL-Anfrage-Struktur manipuliert, um das Gateway dazu zu bringen, bösartige Anfragefragmente in einen verwundbaren Sub-graph zu injizieren.

Da der Sub-graph annimmt, dass das Gateway der einzige Anrufer ist — und dass das Gateway “smart” ist — führt er blind Anfragen für sensible Felder (wie PII, interne IDs oder Admin-Flags) aus, ohne zu prüfen, ob der ursprüngliche Nutzer in diesem Kontext die Berechtigung dazu hat.

Warum ist es “Blind”?

Der Begriff “blind” bezieht sich auf zwei unterschiedliche Ausfallmodi:

Gateway-Blindheit: Das Gateway sieht eine syntaktisch gültige Anfrage. Es prüft sein globales Schema und sagt: “Das sieht gut aus.” Es kennt jedoch nicht notwendigerweise die Geschäftslogik-Beschränkungen des zugrunde liegenden Microservice.

Sub-graph-Blindheit: Der Sub-graph erhält eine Anfrage, die effektiv sagt: “Gib mir die SSN für User ID 123.” Er sieht den ursprünglichen Client-Token oder Kontext nicht — oder ignoriert ihn — und vertraut der Anfrage einfach, weil sie vom IP des Gateways kommt.

---

Aufbau des Angriffs

Szenario: Der “Stitched” Identity Leak

Stellen Sie sich einen Supergraphen mit zwei Sub-graphs vor:

• Users Sub-graph: Handhabt öffentliche Profildaten.
• Billing Sub-graph: Handhabt private Kreditkarteninformationen und Rechnungen.

Der Users Sub-graph definiert:

type User @key(fields: "id") {
  id: ID!
  username: String
  # Nur öffentliche Infos
}

Der Billing Sub-graph erweitert den User-Typ:

extend type User @key(fields: "id") {
  id: ID! @external
  last4Digits: String
  invoices: [Invoice]
  # SENSIBEL: Nur der Nutzer selbst sollte dies sehen
  internalRiskScore: Int
}

Die Schwachstelle

Das Gateway erzwingt, dass ein Nutzer eingeloggt sein muss, um invoices abzufragen. Das Feld internalRiskScore im Billing Sub-graph fehlt jedoch eine spezielle @auth-Direktive, weil die Entwickler annahmen: “Es ist ein internes Feld — das Gateway wird es nicht öffentlich machen.”

Wenn die Schema-Zusammensetzung falsch konfiguriert ist (mehr dazu in realen Beispielen weiter unten), oder wenn der Angreifer Fragment Injection nutzt, kann er die Oberflächenprüfungen des Gateways umgehen.

Der Exploit-Query

query LeakRiskScore {
  node(id: "User:123") {
    ... on User {
      username
      _onBilling_internalRiskScore: internalRiskScore
    }
  }
}

Ablauf

1. Gateway erkennt eine Anfrage für einen Node. Es löst die ID auf.
2. Query Planner erkennt, dass internalRiskScore in den Billing Sub-graph gehört.
3. Injection: Das Gateway generiert eine Fetch-Anfrage an den Billing Sub-graph:

query {
  _entities(representations: [{ __typename: "User", id: "123" }]) {
    ... on User {
      internalRiskScore
    }
  }
}

1. Billing Sub-graph erhält die Anfrage. Es sieht eine Anfrage für internalRiskScore für ID 123. Es prüft nicht, ob der aktuelle Nutzer User 123 ist. Es geht davon aus, dass das Gateway das bereits verifiziert hat.
2. Leck: Das Billing Sub-graph liefert den Score 99 (Hohes Risiko).
3. Antwort: Der Angreifer erhält die privaten Daten.

---

Echte CVEs: Nicht mehr nur Theorie

Dieses Angriffsmuster ist längst Realität. Ende 2025 wurden mehrere CVEs mit hoher Schwere gegen Apollo Federation veröffentlicht — die am weitesten verbreitete federated GraphQL-Laufzeit.

CVE-2025-64530 — Zugriffskontroll-Umgehung bei Schnittstellen (November 2025)

Schweregrad: Hoch

Eine Schwachstelle in der Zusammensetzungslogik von Apollo Federation (Versionen vor 2.9.5, 2.10.4, 2.11.5, 2.12.1) erlaubte es, Anfragen die Zugriffskontrollen bei Schnittstellen und Feldern umgehen. Apollo Federation erlaubte fälschlicherweise benutzerdefinierte Zugriffskontroll-Direktiven (@authenticated, @requiresScopes, @policy) auf Schnittstellen. Da die GraphQL-Spezifikation keine Vererbungsregeln für Direktiven von Schnittstellen zu deren Implementierungen definiert, wurden diese Direktiven nicht an die konkreten Implementierungen weitergegeben.

Ein Angreifer konnte die geschützten Daten durch die Implementierungs-Objekttypen mittels Inline- oder benannter Fragmente abfragen, wodurch die Kontrolle auf der Schnittstelle vollständig umgangen wurde. Der Patch unterdrückte benutzerdefinierte Zugriffskontroll-Direktiven auf Schnittstellen vollständig und ließ die Zusammensetzungslogik von Federation automatisch die korrekten Direktiven auf den Implementierungen generieren.

Maßnahme: Upgrade auf Apollo Federation Zusammensetzung 2.9.5+, 2.10.4+, 2.11.5+ oder 2.12.1+. Bei unpatched Versionen müssen die Zugriffskontrollanforderungen manuell von Schnittstellen auf die jeweiligen Implementierungen übertragen werden.

CVE-2025-64173 — Polymorphe Typen-Authentifizierungsfehler

Schweregrad: Hoch

In Apollo Router Core Versionen 1.61.11 und darunter (und 2.0.0-alpha.0 bis 2.8.1-rc.0) behandelte der Router Zugriffskontroll-Direktiven auf Schnittstellen und deren implementierende Objekttypen falsch. Wenn alle Implementierungen die gleichen Anforderungen hatten, wurden die Direktiven auf die Schnittstelle angewendet, ignorierten jedoch Direktiven auf die implementierenden Objekttypen. Dadurch konnten unautorisierte Anfragen auf Daten zugreifen, die zusätzliche Zugriffskontrollen erforderten.

Maßnahme: Upgrade auf Apollo Router 1.61.12 oder 2.8.1.

CVE-2025-64347 — Umbenannte Direktiven-Umgehung

Schweregrad: Hoch

In Apollo Router Core Versionen 1.61.12-rc.0 und darunter wurden Zugriffskontroll-Direktiven, die über @link-Importe umbenannt wurden, nicht durchgesetzt. Wenn ein Team @authenticated in einen benutzerdefinierten Namen aliasierte, wurde diese Direktive vom Router nicht durchgesetzt — das Feld blieb ungeschützt. Der Fix wurde in Versionen 1.61.12 und 2.8.1 ausgeliefert.

GHSA-m8jr-fxqx-8xx6 — Transitive Feldzugriffssteuerung-Umgehung

Eine weitere Schwachstelle in der Zusammensetzungslogik von Apollo Federation versäumte es, durch @requires oder @fromContext abhängige Felder mit den gleichen Zugriffskontrollanforderungen zu versehen. Ein Angreifer konnte ein Feld abfragen, das von einem geschützten Feld abhängt, ohne die Zugriffskontrolle auszulösen, da nur das abhängige Feld angefragt wurde — nicht das geschützte. Der Fix stellt sicher, dass abhängige Felder die Zugriffskontrollanforderungen der referenzierten Felder erfüllen.

---

Angriffsvariante: Direkter Sub-graph-Expose (der “Shadow Graph”)

Selbst wenn das Gateway perfekt gesichert ist, exponieren viele Organisationen versehentlich ihre Sub-graph-Endpunkte (z.B. billing-service.internal:4000/graphql) durch:

• Fehlkonfigurierte Load Balancer oder Ingress-Controller
• SSRF-Schwachstellen in angrenzenden Diensten
• Vorhersehbare interne DNS-Namen, die aus einer DMZ erreichbar sind

Wie die Sicherheitsrichtlinien von Apollo anmerken, umgehen Sie bei direktem Zugriff auf Sub-graphs die Sicherheitskontrollen des Routers vollständig. Die _entities-Abfrage — die spezielle Anfrage, die das Gateway nutzt, um federated Daten abzurufen — wird so zu einem direkten, unautorisierten Datenzugriff für jeden, der den Endpunkt erreichen kann.

Wenn ein Angreifer den Sub-graph direkt erreicht, kann er eine Gateway-Anfrage simulieren:

POST http://billing-service.internal:4000/graphql

{
  "_entities": [{ "__typename": "User", "id": "456" }],
  "query": "query { _entities(representations: [{ __typename: \"User\", id: \"456\" }]) { ... on User { internalRiskScore invoices { amount } } } }"
}

Kein JWT. Kein Auth-Header. Nur direkter interner Zugriff.

---

Warum traditionelle WAFs das komplett übersehen

Ein Web Application Firewall arbeitet hauptsächlich anhand von HTTP-Anfrage-Signaturen — URL-Muster, Payloads, bekannte bösartige Strings. Federated Sub-graph Injection erzeugt:

• Syntaktisch gültige GraphQL-Anfragen
• Standard POST /graphql-Anfragen mit Content-Type: application/json
• Keine SQL-, Shell-Befehle oder klassische Injection-Payloads
• Anfragen, die “erfolgreich” aus Sicht der Gateway-Logs sind, mit einer 200 OK-Antwort

Das bedeutet, die Zugriffsprotokolle des Gateways zeigen keine Anomalie. Der Bruch ist auf jeder Ebene unsichtbar, außer im Sub-graph selbst — der, per Design, kein Bewusstsein dafür hat, dass die Anfrage unautorisiert war. Das ist das Kernproblem bei der Compliance: Ein GDPR- oder CCPA-Audittrail zeigt eine legitime Nutzeranfrage mit 200 an, ohne Aufzeichnung, welche spezifischen Sub-graph-Felder tatsächlich zurückgegeben wurden.

---

Defense in Depth: Sicherung des Supergraphen

Der Wechsel von “Gateway-Vertrauen” zu “Zero Trust” erfordert Kontrollen auf jeder Ebene.

1. Sub-graph-Authentifizierung (Der Goldene Grundsatz)

Verlassen Sie sich niemals ausschließlich auf das Gateway für die Autorisierung. Jeder Sub-graph muss unabhängig prüfen, wer der Nutzer ist und ob er Zugriff auf ein bestimmtes Objekt hat.

// Im Resolver des Billing Sub-graph
const resolvers = {
  User: {
    internalRiskScore: async (userEntity, args, context) => {
      // KRITISCH: Immer die Autorisierung im Resolver prüfen
      if (context.userId !== userEntity.id && !context.isAdmin) {
        throw new AuthenticationError("Nicht autorisiert, Risikowert zu sehen");
      }
      return fetchRiskScore(userEntity.id);
    }
  }
};

Der Kontext muss durch Weitergabe des ursprünglichen JWT vom Gateway an den Sub-graph bei jeder Anfrage gefüllt werden. Das ist unverhandelbar.

2. Sichere Gateway-zu-Sub-graph-Kommunikation

Sub-graphs sollten nur Anfragen vom legitimen Gateway akzeptieren. Zwei starke Optionen:

Mutual TLS (mTLS): Die stärkste Verteidigung. Sub-graphs akzeptieren nur Verbindungen von einem Client-Zertifikat, das an das Gateway ausgestellt wurde. Jede direkte Anfrage — vom Angreifer oder einer Fehlkonfiguration bei SSRF — wird beim TLS-Handshake abgelehnt.

HMAC-signierte Anfragen: Das Gateway signiert jede Anfrage an den Sub-graph mit einem gemeinsamen Geheimnis. Der Sub-graph prüft die Signatur vor der Verarbeitung. Hinweis: Ein einfaches statisches Header-Feld wie x-gateway-secret: "hardcoded-value" ist nicht ausreichend — Geheimnisse können in Quellcode, Logs und Umgebungsvariablen geleakt werden.

3. Netzwerktrennung — Halten Sie Sub-graphs intern

Wie die offizielle Sicherheitsdokumentation von Apollo betont, müssen Sub-graphs nur vom Router zugänglich sein. Sie sollten niemals vom öffentlichen Internet, aus DMZ-Segmenten oder von Diensten, die nicht das Gateway sind, erreichbar sein. Erzwingen Sie dies auf Netzwerkebene (Sicherheitsgruppen, VPC-Richtlinien, Kubernetes NetworkPolicy-Objekte) — nicht nur per Konvention.

4. Deaktivieren Sie _service und _entities auf öffentlich zugänglichen Endpunkten

Das _service-Feld gibt das rohe SDL (Schema Definition Language) des Sub-graph aus. Das _entities-Feld ist der Einstiegspunkt für Federation-Anfragen. Wenn Ihre Architektur unbedingt einen Sub-graph außerhalb des Gateways zugänglich machen muss (selten und nicht empfohlen), verwenden Sie Middleware, um diese Felder zu blockieren, es sei denn, die Anfrage stammt von einer vertrauenswürdigen Gateway-IP.

5. Patchen und aktuell bleiben

Die oben genannten CVEs zeigen, dass auch gut gestaltete Federation-Laufzeiten bei der Zusammensetzung Logikfehler aufweisen können. Sie sollten:

• Sicherheitswarnungen für Apollo Router, Apollo Federation-Zusammensetzung und andere verwendete Federation-Bibliotheken abonnieren.
• apollo check und rover subgraph check in Ihre CI/CD-Pipeline integrieren, um Schema-Access-Control-Regressions vor Deployment zu erkennen.
• Tools wie GraphQL Inspector oder Apollo GraphOS schema checks verwenden, um Felder zu markieren, die öffentlich sind, aber sensible Typen zurückgeben.

6. Zugriffskontrolle bei @requires und @fromContext-Abhängigkeiten durchsetzen

Gemäß GHSA-m8jr-fxqx-8xx6 sollten Sie Ihr Schema auf Felder prüfen, die @requires oder @fromContext verwenden, um auf geschützte Daten zuzugreifen. Stellen Sie sicher, dass diese abhängigen Felder passende Zugriffskontroll-Direktiven tragen. Die gepatchte Zusammensetzungsbibliothek wird dies automatisch durchsetzen, Teams mit älteren Versionen müssen dies manuell prüfen.

7. Abfragekostenanalyse im Sub-graph

Angreifer können auch federated injection nutzen, um Denial-of-Service-Angriffe durch tief verschachtelte federated Beziehungen auszuführen. Implementieren Sie Abfrage-Tiefenbegrenzung und Kostenanalyse auf Sub-graph-Ebene — nicht nur im Gateway — um Ressourcenerschöpfung durch bösartig gestaltete Entity-Queries zu verhindern.

---

Geschäftliche und Compliance-Auswirkungen

Die Konsequenzen eines erfolgreichen Federated Sub-graph Injection-Angriffs gehen weit über den unmittelbaren Datenleck hinaus.

Datenpanne: PII (E-Mails, IDs, Finanzdaten) kann über Microservice-Grenzen hinweg exfiltriert werden, aus Diensten, die als geschützt galten.

Verstöße gegen Compliance: Da die Gateway-Logs eine 200 OK-Antwort für eine legitime Anfrage zeigen, fehlt eine klare Audit-Trail für unbefugten Zugriff. GDPR- und CCPA-Untersuchungen könnten feststellen, dass Organisationen keinen Nachweis erbringen können, dass der Zugriff auf bestimmte Datenfelder ordnungsgemäß kontrolliert wurde — selbst wenn eine Gateway-Authentifizierung vorhanden war.

Reputationsschaden: Federated-Architekturen werden genau deshalb eingesetzt, weil sie skalieren. Ein Verstoß in dieser Schicht kann Daten in allen Services des Supergraphen gleichzeitig beeinträchtigen.

---

Zusammenfassung

Federated GraphQL bietet enorme Entwicklergeschwindigkeit, aber es zerbricht grundlegend die traditionelle Sicherheitsperimeter. Federated Sub-graph Injection gedeiht im Zwischenraum zwischen “Smart Gateway” und “Dumb Sub-graph” — und wie die im späten 2025 offenbarten CVEs zeigen, können sogar die Zusammensetzungslogik großer Federation-Laufzeiten Zugriffskontroll-Umgehungen einführen, die für herkömmliche Sicherheits-Tools unsichtbar sind.

Das Prinzip, das man verinnerlichen sollte, ist einfach: Autorisierungslogik muss mit den Daten reisen, nicht nur mit der Anfrage. Sicherheitsteams sollten ihre Supergraphs heute auditieren, jeden Sub-graph als öffentlich zugänglichen Service aus Sicht der Autorisierung behandeln und sicherstellen, dass Zugriffskontrollen auf jeder Ebene des Graphen unabhängig durchgesetzt werden.