Anfrage und Aufwand verstehen
Das Beispiel nutzt ein fiktives Schema: customer, orders und total müssen in der echten API existieren. Eine Anfrage kann mehrere Serverzugriffe auslösen. Auch REST kann angepasste Antworten liefern. Ein HTTP-Endpunkt ist bei GraphQL üblich, aber keine Pflicht für jede Architektur.
query RecentOrders($id: ID!) {
customer(id: $id) {
name
orders(first: 5) {
nodes { id total }
}
}
}Eine typische Aufgabe vergleichen
- Messen Sie Bytes, Latenz, Fehler und Serverarbeit bei gleicher Oberfläche, gleichen Rechten und realistischen Datenmengen.
- Prüfen Sie Paginierung, gebündelte Lesezugriffe gegen N+1, Caching und Trennung von Kontodaten.
- Bewerten Sie Schemaänderungen, ältere Clients und Betriebsaufwand. REST beizubehalten kann einfacher sein.
Rechte und Lastgrenzen durchsetzen
Authentifizieren Sie Aufrufe und autorisieren Sie Objekte und Felder in der Geschäftslogik. Begrenzen Sie Listen, Tiefe, Aliase, gebündelte Operationen und geschätzte Kosten. Die Anfragefrequenz allein beschreibt die Last nicht. Versteckte Introspektion ersetzt diese Kontrollen nicht; testen Sie Ablehnungen und Teilantworten.
Primärquellen
Steuern Sie das GraphQL-Schema und die Abfragekosten.
GraphQL ermöglicht es Clients, Felder auszuwählen. Diese Flexibilität erfordert jedoch eine Objekt- und Feldautorisierung. Eine Größen- oder Tiefenbegrenzung allein ersetzt nicht die Messung des durch eine Abfrage verursachten Aufwands.
- Testen Sie sensible Felder und Objekte, die einem anderen Konto gehören.
- Begrenzen und überwachen Sie Kosten, Tiefe und Anfragevolumen des Dienstes.
- Aktualisieren Sie Schemaänderungen und testen Sie ältere Clients.
Primärquelle: OWASP — GraphQL Cheat Sheet. Verwandte Methode: den praktischen Leitfaden lesen.
ETag, HTTP-Cache und gleichzeitige Änderungen
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
REST and GraphQL: separate representation and authorisation
An HTTP ETag applies to a selected representation. It is neither permission for every returned object nor a universal consistency contract for GraphQL entities.
- Define which response variants have their own validators.
- Test object and field access independently from HTTP conditions.
- Do not automatically apply the PUT scenario to a GraphQL mutation; specify its concurrency contract.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
