GraphQL absichern: Rechte und Aufwand jeder Operation begrenzen

Ein Endpunkt kann viele getrennte Datenzugriffe auslösen

GraphQL beschreibt die angefragten Felder in einer Operation. Die Anwendung löst sie über ihre Ausführungslogik auf, häufig mit sogenannten Resolvern. Ein Resolver liefert den Wert eines Feldes oder delegiert dafür an eine andere Schicht. Der Zugriff auf /graphql ist deshalb erst der Eingang, nicht die gesamte Berechtigungsentscheidung.

Das folgende synthetische Dokument fragt Titel und Kommentare eines Berichts ab. Es setzt ein passendes fiktives Schema voraus; es wurde nicht an einem GraphQL-Server ausgeführt.

query ReportOverview($id: ID!, $first: Int!) {
  report(id: $id) {
    title
    comments(first: $first) {
      nodes {
        text
      }
    }
  }
}

Der Server muss unter anderem entscheiden: Darf diese Person den Bericht sehen? Darf sie seine Kommentare sehen? Wie viele Kommentare sind pro Abfrage erlaubt? Ein Pflichtargument vom Typ Int! beweist weder einen sinnvollen Wertebereich noch eine Berechtigung. Die GraphQL-Validierung prüft den Vertrag des Schemas; zusätzliche Werte- und Geschäftsregeln bleiben nötig. GraphQL Specification, Validierung und Ausführung.

Teilen Sie Berechtigungslogik mit den anderen Zugriffspfaden

Ermitteln Sie vor der Ausführung den geprüften Aufruferkontext. Verwenden Sie ihn bei jedem geschützten Objekt- und Feldzugriff. Wenn ein Bericht sowohl über report(id: ...) als auch über eine Teamliste oder ein verschachteltes Projekt erreichbar ist, müssen diese Wege dieselbe fachliche Regel beachten.

Die offizielle GraphQL-Dokumentation empfiehlt, Autorisierung in einer gemeinsamen Geschäftslogik zu verankern. Resolver rufen diese Logik auf, statt ihre eigenen abweichenden Regeln zu kopieren. Eine selbst definierte Schema-Direktive wie @auth ist nur dann wirksam, wenn Ihre Implementierung ihr tatsächlich die passende Durchsetzung gibt. GraphQL: Authorization.

Prüfen Sie Mutation, Objekt und veränderbare Felder getrennt. Wer eine Mutation aufrufen darf, darf damit nicht automatisch jedes referenzierte Objekt verändern. Für Mandantenkontext und zwischengespeicherte Ergebnisse gilt dieselbe Regel: Ein Cachetreffer darf nicht Daten aus einem anderen Aufrufer- oder Mandantenkontext übernehmen. Die Grundlagen liefern BOLA/IDOR, Feldrechte und Mandantentrennung.

Tiefe, Breite und tatsächliche Kosten sind verschiedene Grenzen

Eine flache Abfrage kann viele teure Felder enthalten. Eine kurze Abfrage kann große Listen anfordern. Dieselbe Zahl von HTTP-Requests kann deshalb sehr unterschiedlichen Aufwand auslösen.

Setzen Sie Pagination serverseitig durch. Ein Clientargument first braucht eine Obergrenze; sein bloßes Vorhandensein macht eine Liste nicht begrenzt. Bei verschachtelten Listen muss die Gesamtauswirkung berücksichtigt werden. Kostenmodelle können teuren Feldern Gewichte geben und Mengenargumente einbeziehen; sie benötigen einen Abgleich mit dem eigenen Datenzugriff. Es gibt keine allgemeingültige sichere Maximaltiefe. GraphQL: Security, Demand control, OWASP GraphQL.

Messen Sie die legitimen Operationen Ihrer eigenen Clients in einer geeigneten Umgebung und wählen Sie nachvollziehbare Budgets mit begrenztem Spielraum. Prüfen Sie auch, ob ein Timeout die teure nachgelagerte Arbeit tatsächlich beendet. Eine abgebrochene HTTP-Verbindung muss nicht bedeuten, dass eine Datenbankabfrage oder ein externer Auftrag aufgehört hat.

Verwechseln Sie Aliases, mehrere Operationen und Batching nicht

Ein Alias benennt ein Ergebnisfeld um. Mehrere Aliases können innerhalb einer Operation verschiedene Auflösungen desselben Feldes anfordern. Berücksichtigen Sie deshalb die tatsächlich ausgeführte Feldarbeit, statt nur den Namen des Endpunkts zu zählen.

Ein Dokument kann außerdem mehrere benannte Operationen enthalten. Das bedeutet nach der GraphQL-Spezifikation nicht, dass sie alle gemeinsam ausgeführt werden: Der Request wählt eine Operation; bei mehreren ist der Operationsname erforderlich. Davon zu unterscheiden ist optionales Batching, bei dem eine Implementierung mehrere GraphQL-Requests über einen Transportaufruf annimmt. Dieses Verhalten müssen Sie ausdrücklich mit Ihrer Bibliothek und Ihrem Serververtrag klären. GraphQL Specification, Abschnitt 6.1.

Wenn Sie Batching unterstützen, bestimmen Sie sowohl Grenzen je Operation als auch für den gesamten Batch. Prüfen Sie Authentifizierung, Kostenabrechnung und Fehlerbehandlung in dieser Verarbeitung. Das Abschalten einer unnötigen Batchfunktion kann den Vertrag vereinfachen; Aliases und andere reguläre GraphQL-Funktionen bleiben davon getrennte Themen.

Bekannte Dokumente können helfen, ersetzen aber keine Rechte

Für ausschließlich eigene Clients können vorab geprüfte und ausdrücklich zugelassene Dokumente den erlaubten Operationsumfang beschränken. Der Server akzeptiert dann nur registrierte Dokumentkennungen beziehungsweise die zugehörigen freigegebenen Operationen. Das Verfahren muss zu Ihrem Veröffentlichungsablauf passen: Neue Clientversionen benötigen ihre erlaubten Dokumente rechtzeitig.

Eine gewöhnliche Persistierung oder ein Hashcache ist nicht automatisch eine solche Zulassungsliste. Wenn beliebige neue Dokumente zur Laufzeit registriert werden dürfen, besteht die zusätzliche Vertrauensgrenze nicht in gleicher Weise. Auch bekannte Dokumente erhalten veränderliche Variablen: Die Objekt-ID, Menge und fachlichen Werte brauchen weiterhin ihre eigenen Prüfungen.

Für eine API mit frei arbeitenden externen Clients ist eine vollständige Vorabfestlegung aller Operationen häufig unpassend. Hier tragen Schema-, Werte-, Rechte- und Ressourcenregeln die Nutzung. Die Entscheidung sollte die vorgesehene API-Aufgabe erhalten, statt ihren wesentlichen Nutzen still abzuschalten.

Introspection und Fehlerdaten bewusst behandeln

Introspection macht das Schema abfragbar und kann für Entwicklungswerkzeuge oder externe Nutzer beabsichtigt sein. Sie abzuschalten kann die unmittelbare Erkundbarkeit reduzieren, ersetzt aber weder Autorisierung noch Ressourcenbegrenzung. Auch Fehlermeldungen können Teile des Schemas verraten. Entscheiden Sie nach Clientkreis und Betriebsumgebung, welche Entwicklungsinformationen sichtbar sein sollen.

GraphQL-Antworten können Teildaten und Fehler gemeinsam enthalten. Beurteilen Sie daher data, errors und den konkreten Vertrag; weder ein HTTP-200 noch irgendein Fehler beweist für sich, ob unerlaubte Daten ausgegeben wurden. Interne Ausnahmen und vertrauliche Werte gehören nicht ungefiltert in Fehlernachrichten oder Erweiterungsfelder. GraphQL Specification, Response, GraphQL: Security.

Die Core-Spezifikation schreibt keinen bestimmten Transport vor. Der ergänzende GraphQL-over-HTTP-Text ist am Quellenstichtag ein Stage-2-Entwurf. Behandeln Sie dessen Medientyp- und Statuscodeempfehlungen entsprechend und prüfen Sie, was Ihr Server und seine Clients tatsächlich unterstützen. Ein Entwurf ist kein Beleg, alle bestehenden APIs müssten bereits genau denselben HTTP-Vertrag erfüllen.

Bei Browsercookies bleiben CORS und CSRF-Schutz zusätzlich relevant. Auch ein einziger GraphQL-Endpunkt umgeht diese Browserbedingungen nicht.

Führen Sie Grenzen mit nachvollziehbaren eigenen Gegenproben ein

Prüfen Sie in einer isolierten Umgebung eine legitime Operation und einen unerlaubten Objekt- oder Feldzugriff mit eigenen Testidentitäten. Vergleichen Sie denselben Datenzugriff über alternative Resolverwege. Kontrollieren Sie bei Teilfehlern die verbleibenden Daten und bei Mutationen den tatsächlichen Zustand.

Für Ressourcenregeln reichen zunächst kleine kontrollierte Grenzfälle: eine zulässige Listenmenge und eine knapp darüber, eine erlaubte Operation und eine knapp oberhalb des festgelegten Kostenbudgets. Beobachten Sie auch die nachgelagerte Arbeit. Das ist eine gezielte Funktionsprüfung, kein allgemeiner Last- oder Verfügbarkeitsnachweis.

Planen Sie eine Rücknahme, die gültige Clients wieder unterstützt und eine wirksame Grenze erhält: etwa eine zuvor geprüfte Budgetkonfiguration oder die Sperre einer einzelnen problematischen Operation. Alle Grenzen auf „unbegrenzt“ zu setzen oder Feldrechte zu entfernen wäre keine sichere Reparatur. Der API Security Check führt keine GraphQL-Queries, Resolver- oder Kostenprüfungen aus. Für eigene Nachweise führt API-Sicherheit selbst prüfen weiter; öffentliche Antwortsignale ordnet HTTP-Befunde lesen ein.

Passende nächste Schritte