GraphQL-Sicherheit: Introspection, übermäßige Queries und Autorisierungsrisiken

GraphQL ist ein flexibler API-Ansatz, der es dem Client erlaubt, aus einem einzigen Endpunkt genau die benötigten Daten abzufragen. Diese Flexibilität ist mächtig, bringt aber von REST verschiedene Risiken: Schema-Preisgabe, Ressourcenerschöpfung durch verschachtelte Queries und Autorisierung auf Feldebene. Dieser Artikel behandelt GraphQL-spezifische Risiken und deren Abwehr.

Introspection: Preisgabe des Schemas

GraphQLs “Introspection” lässt einen Client das gesamte Schema abfragen (Typen, Felder, Mutationen). In der Entwicklung nützlich, doch in der Produktion offen gelassen liefert es einem Angreifer eine vollständige Karte der API-Oberfläche.

• Empfehlung: Introspection in der Produktion deaktivieren oder auf authentifizierte Entwickler beschränken. Das ersetzt nicht das Beheben echter Fehler, verbirgt aber die Angriffsflächen-Karte.

Übermäßige/verschachtelte Queries: Ressourcenerschöpfung

GraphQLs Flexibilität bedeutet, dass eine einzelne Query sehr tief oder sehr breit sein kann. Ein bösartiger Client kann mit verschachtelten Beziehungen eine sehr teure Query senden und den Server überlasten (eine Form von DoS).

• Query-Tiefenbegrenzung.
• Query-Kosten-/Komplexitätsanalyse: jedem Feld Kosten zuweisen und Queries über einem Budget ablehnen.
• Pflicht-Pagination bei Listenfeldern.
• Rate Limiting am Endpunkt.

Autorisierung: Kontrolle auf Feldebene

Bei einem einzigen Endpunkt genügt “schütze den Endpunkt” nicht; Autorisierung muss auf Feld-/Typebene angewendet werden. Selbst wenn ein Nutzer auf einen Typ zugreifen kann, darf er nicht auf dessen sensible Felder zugreifen (z. B. die E-Mail eines anderen Nutzers). BOLA/BFLA-Risiken gelten auch in GraphQL und erfordern Prüfungen auf Feldebene.

Fehlermeldungen

Ausführliche GraphQL-Fehlermeldungen können interne Struktur und Schema preisgeben. Vereinfachen Sie die Fehlerausgabe in der Produktion; protokollieren Sie interne Details nur.

Zusammenfassung

GraphQLs Flexibilität bringt eigene Risiken: Introspection in der Produktion deaktivieren, Ressourcenerschöpfung mit Tiefen-/Komplexitätslimits und Rate Limiting verhindern, Autorisierung auf Feldebene statt am Endpunkt anwenden und Fehlermeldungen vereinfachen. Zusammen machen diese die Flexibilität sicher.

Quellen: OWASP GraphQL Cheat Sheet, OWASP API Security Top 10.

Ist Ihre GraphQL-API für Introspection- oder Query-Risiken anfällig? Der Scan von CyberTestify bewertet erkannte API-Endpunkte.