Zurück zum Learning Center

Was ist GraphQL-API-Sicherheit?

GraphQL-API-Sicherheit bezeichnet die Praktiken und Technologien, die verwendet werden, um GraphQL-APIs vor unbefugtem Zugriff, bösartigen Anfragen, Datenexposition, Denial-of-Service-Angriffen und Missbrauch zu schützen.

GraphQL, eine Open-Source-Query-Sprache, bietet Clients (Computern, Telefonen oder Browsern, Softwareprogrammen) erhebliche Flexibilität in Bezug auf die von ihnen angefragten Daten. Anstatt sich auf vordefinierte Endpunkte zu verlassen, die feste Antworten zurückgeben, können Clients Querys erstellen, die genau die benötigten Felder und zugehörigen Daten angeben.

Diese Flexibilität kann APIs für Entwickler effizienter machen, bringt aber auch ganz spezifische Sicherheitsüberlegungen mit sich. Eine unzureichend geschützte GraphQL-API kann es Angreifern ermöglichen, rechenintensive Querys zu erstellen, sensible Teile eines API-Schemas aufzudecken, auf Daten zuzugreifen, für die sie keine Autorisierung besitzen, oder eine große Anzahl bösartiger Anfragen zu automatisieren.

Effektive GraphQL-Sicherheit erfordert daher eine Kombination aus Authentifizierung, Autorisierung, Query-Kontrollen, Eingabevalidierung, Rate Limiting, Anwendungssicherheit, Überwachung und sicherem API-Design.

Welche Tools und Praktiken umfasst die GraphQL-API-Sicherheit?

GraphQL-API-Sicherheit schützt die Daten, Operationen und Infrastruktur, die über eine GraphQL-API bereitgestellt werden. Eine GraphQL-API stellt in der Regel ein Schema bereit, das die verfügbaren Datentypen und die Operationen beschreibt, die Clients ausführen können. Clients senden Querys oder Mutationen, die die gewünschten Informationen oder Aktionen beschreiben.

Der Schutz von GraphQL-APIs umfasst Praktiken und Tools rund um: 

Das Ziel ist es, legitimen Clients die Funktionen bereitzustellen, die sie benötigen, ohne die Flexibilität von GraphQL einzuschränken. 

Wie funktioniert die GraphQL-API-Sicherheit?

Eine GraphQL-Anfrage erreicht im Allgemeinen einen einzelnen HTTP-Endpunkt wie „/graphql“. Die Anfrage enthält eine Query, die den Betrieb beschreibt, den der Client vom Server ausführen lassen möchte. Ein legitimer Client fordert möglicherweise Informationen über ein Produkt und dessen Verfügbarkeit an. 

Der GraphQL-Server parst die Query, validiert sie anhand des Schemas, ruft die erforderlichen Resolver auf, ruft die entsprechenden Daten ab und gibt eine Antwort zurück.

Sicherheitskontrollen können in mehreren Phasen dieses Prozesses angewendet werden. 

Die Authentifizierung identifiziert den Client

Die Authentifizierung bestimmt, wer oder was die Anfrage stellt. GraphQL-APIs können je nach Architektur der Anwendung Mechanismen wie Session-Cookies, API-Schlüssel, OAuth oder JSON Web Tokens (JWTs) verwenden.

Die Autorisierung steuert, was der Client tun kann

Authentifizierung allein reicht nicht aus. Nachdem der Client identifiziert wurde, muss die Anwendung feststellen, ob diese Identität Zugriff auf ein bestimmtes Objekt, Feld oder eine bestimmte Operation hat.

Die Autorisierung sollte im Business-Logik-Layer durchgesetzt werden, anstatt sich ausschließlich auf GraphQL-Resolver zu verlassen oder Teile des Schemas zu verbergen. 

Query-Kontrollen begrenzen kostenintensive Operationen

GraphQL-Querys können verschachtelt werden. Ohne entsprechende Kontrollen könnte ein Client eine Query übermitteln, die erhebliche CPU-, Speicher- oder Datenbankarbeit oder Aufrufe nachgelagerter Services erfordert.

Apps können Tiefe, Breite, Komplexität oder Kosten von Querys analysieren und Anfragen ablehnen, die akzeptable Limits überschreiten.

Rate Limiting kontrolliert den Anfrageverbrauch

Rate Limits können kontrollieren, wie häufig Clients Operationen durchführen. Für GraphQL benötigen Unternehmen möglicherweise ausgefeiltere Kontrollen als das einfache Zählen von HTTP-Anfragen, da zwei Anfragen an denselben /graphql-Endpunkt drastisch unterschiedliche Rechenkosten verursachen können.

Anwendungssicherheitskontrollen überprüfen bösartigen Traffic

Eine Web Application Firewall (WAF) oder eine Web-App- und API-Schutz-Plattform kann Anfragen auf Angriffe wie Injection und andere bösartige Payloads überprüfen, bevor sie die GraphQL-App erreichen.

Monitoring erkennt ungewöhnliches Verhalten

Logs und Sicherheitstelemetrie können unerwartete Query-Muster, wiederholte Autorisierungsfehler, ungewöhnlich aufwendige Anfragen, bösartige Bots oder Traffic-Spitzen aufdecken. Zusammen bieten diese Kontrollen eine tiefgehende Verteidigung rund um die GraphQL-API.

Warum ist GraphQL-API-Sicherheit notwendig?

GraphQL macht eine API nicht von Natur aus unsicher. Einige der Funktionen, die GraphQL so leistungsfähig machen, bringen jedoch auch Sicherheitsaspekte mit sich, die sich von herkömmlichen REST-APIs unterscheiden. 

Im Folgenden finden Sie Risiken, die sich aus der Natur von GraphQL ergeben, und Gründe, warum die GraphQL-API-Sicherheit so wichtig ist. 

Clients haben erhebliche Kontrolle über Querys

Bei einer REST-API definiert der Server üblicherweise Endpunkte, die vorgegebene Datenstrukturen zurückgeben. Stattdessen ermöglicht GraphQL dem Client, die gewünschten Felder und Beziehungen anzugeben. Ohne angemessene Einschränkungen kann ein böswilliger Client diese Flexibilität möglicherweise nutzen, um kostspielige oder missbräuchliche Querys zu erstellen.

Ein einzelner Endpoint kann viele Operationen offenlegen

Herkömmliche API-Sicherheit verwendet URL-Pfade häufig als wichtigen Bestandteil der Sicherheitsrichtlinie. GraphQL leitet üblicherweise viele verschiedene Querys und Mutationen über denselben Endpunkt weiter. Ein Sicherheitssystem kann daher nicht davon ausgehen, dass alle Anfragen an /graphql dieselbe Operation oder dasselbe Risiko darstellen.

Querys können rechenintensiv werden

GraphQL ermöglicht verschachtelte Beziehungen. Eine tief verschachtelte oder außergewöhnlich breite Query kann viele Resolver-Aufrufe, Datenbankoperationen oder nachgelagerte Anfragen verursachen. Angreifer können dieses Verhalten absichtlich instrumentalisieren, um Anwendungsressourcen zu verbrauchen.

Autorisierung kann granular werden

Ein Nutzer darf möglicherweise auf ein GraphQL-Objekt zugreifen, auf ein anderes jedoch nicht, oder auf einige Felder eines Objekts, auf andere jedoch nicht. Jede relevante Datenzugriffsoperation erfordert daher eine entsprechende Autorisierung.

Schemainformationen können Angreifern helfen

GraphQL unterstützt Introspektion, wodurch Clients Informationen über das Schema abfragen können. Dies ist für Entwicklertools äußerst nützlich. In der Produktivumgebung sollten Organisationen jedoch eine bewusste Entscheidung darüber treffen, ob eine uneingeschränkte Introspektion erforderlich ist, da Schemainformationen Angreifern dabei helfen können, verfügbare Operationen zu verstehen.

APIs ziehen automatisierten Missbrauch an

Angreifer können Bots nutzen, um Aufklärung zu betreiben, Zugangsdatenangriffe durchzuführen, ressourcenintensive Operationen abzufragen, Daten zu scrapen oder Schwachstellen in großem Maßstab auszunutzen. GraphQL-Sicherheit muss daher sowohl Schwachstellen als auch den Missbrauch legitimer Funktionen berücksichtigen.

Was sind häufige GraphQL-API-Sicherheitsrisiken?

Fehlerhafte Autorisierung

Eine API authentifiziert möglicherweise einen Nutzer korrekt, überprüft jedoch nicht, ob dieser Nutzer auf ein bestimmtes Objekt oder Feld zugreifen darf. Beispielsweise sollte die Änderung eines Objektbezeichners in einer Query es einem Kunden nicht ermöglichen, die privaten Informationen eines anderen Kunden abzurufen.

Übermäßige Query-Tiefe

Ein Angreifer kann tief verschachtelte Querys erstellen, die immer größere Mengen an Rechenleistung erfordern. Tiefenlimits können verhindern, dass Anfragen die angemessenen Verschachtelungsanforderungen einer Anwendung überschreiten.

Query-Komplexität und Ressourcenerschöpfung

Die Tiefe ist nicht das einzige Problem – eine relativ flache Query könnte Tausende von Objekten anfragen oder aufwendige Resolver aufrufen. Eine Analyse der Query-Kosten oder -Komplexität kann einen präziseren Schutz bieten, indem die für die Ausführung einer Anfrage erforderlichen Ressourcen abgeschätzt werden.

Batching-Missbrauch

GraphQL-Implementierungen ermöglichen möglicherweise das gemeinsame Senden mehrerer Operationen. Obwohl Batching die Effizienz legitimer Anwendungen verbessern kann, versuchen Angreifer möglicherweise, es zur Umgehung einfacher anfragebasierter Rate Limits zu nutzen oder eine große Anzahl von Operationen mit weniger HTTP-Anfragen durchzuführen.

Injection-Angriffe

GraphQL-Resolver interagieren häufig mit Datenbanken und anderen Backend-Systemen. Wenn Nutzereingaben nachträglich unsicher verarbeitet werden, können GraphQL-Anwendungen dennoch anfällig für SQL Injection, Command Injection und andere Injection-Angriffe sein.

Information disclosure (Datenschutzverletzung)

Ausführliche Fehlermeldungen können Stack Traces, interne Implementierungsdetails oder andere für Angreifer nützliche Informationen offenlegen. Wenn aktiviert, kann die Schema-Introspektion auch Informationen über verfügbare Typen und Operationen offenlegen.

Denial of Service

Aufwendige Querys, übermäßige Aliase, Batching, wiederholte Anfragen oder andere ressourcenintensive Vorgänge können dazu verwendet werden, die App-Performance oder -Verfügbarkeit zu beeinträchtigen.

Automatisiertes Scraping und Missbrauch

Eine technisch valide GraphQL-Query kann dennoch missbräuchlich sein, wenn sie automatisch in großem Umfang ausgeführt wird. Bot-Management und Rate Limiting können wichtige Ergänzungen zu einer schwachstellenorientierten API-Sicherheit sein.

Was sind die Best Practices für die GraphQL-API-Sicherheit?

GraphQL-Sicherheit sollte mit der Anwendung selbst beginnen und durch Laufzeitsicherheitskontrollen verstärkt werden.

1. Vorschreiben einer starken Authentifizierung

Schützen Sie nicht öffentliche Operationen mit geeigneten Authentifizierungsmechanismen. Verwenden Sie etablierte Identitätsstandards und eine sichere Sitzungs- oder Token-Handhabung, anstatt ohne triftigen Grund individuelle Authentifizierungsschemata zu erstellen.

2. Durchsetzen einer Autorisierung auf jedem relevanten Layer

Gehen Sie nicht davon aus, dass authentifizierte Nutzer auf jedes über das Schema bereitgestellte Objekt Zugriff haben sollten. Die Autorisierung sollte an die Geschäftsregeln der Anwendung gekoppelt sein und konsequent durchgesetzt werden, wenn auf Daten zugegriffen oder diese geändert werden.

3. Begrenzung der Query-Tiefe

Setzen Sie angemessene Limits dafür, wie tief Querys verschachtelt werden können. Das angemessene Maximum hängt von den legitimen Anforderungen der Anwendung ab.

4. Implementierung einer Query-Kostenanalyse

Weisen Sie Feldern oder Operationen basierend auf deren erwartetem Ressourcenverbrauch Kosten zu und lehnen Sie Anfragen ab, deren berechnete Kosten einen akzeptablen Schwellenwert überschreiten. Dies kann einen sinnvolleren Schutz bieten als Tiefenlimits allein.

5. Rate Limiting

Wenden Sie Rate Limiting auf Clients entsprechend dem Anwendungsrisiko und normalen Nutzungsmustern an. Berücksichtigen Sie nach Möglichkeit die tatsächliche GraphQL-Operation oder die Ressourcenkosten, anstatt jede HTTP-Anfrage als gleichwertig zu behandeln.

6. Kontrolle von Batching und Aliasen

Legen Sie sinnvolle Limits dafür fest, wie viele Vorgänge, Aliasse oder Felder ein Client gleichzeitig anfragen kann. Dies kann die Möglichkeiten verringern, herkömmliches Rate Limiting zu umgehen oder unerwartet kostspielige Workloads zu erstellen.

7. Überprüfung aller Eingaben

Behandeln Sie GraphQL-Argumente als nicht vertrauenswürdige Eingabe. Verwenden Sie Schema-Validierung, parametrisierte Datenbank-Querys, sichere APIs und eine kontextangemessene Ausgabeverarbeitung.

8. Treffen einer bewussten Entscheidung zur Introspektion

Introspektion ist wertvoll für die Entwicklung und Tools, aber der Zugriff auf die Produktivumgebung sollte den Anforderungen des Unternehmens entsprechen. Das Deaktivieren oder Einschränken der Introspektion ist kein Ersatz für eine Autorisierung, kann jedoch die unnötige Offenlegung von Informationen reduzieren.

9. Vermeiden von übermäßigen Fehlerdetails

Geben Sie nützliche Fehlermeldungen an legitime Clients zurück, ohne Stack Traces, Datenbankinformationen, interne Service-Details oder andere vertrauliche Implementierungsinformationen offenzulegen.

10. Verwendung von Zeitüberschreitungen

Querys sollten Serverressourcen nicht unbegrenzt verbrauchen dürfen. Angemessene Ausführungs-, Datenbank- und Downstream-Service-Timeouts können die Auswirkungen unerwartet teurer Operationen begrenzen.

11. Schutz des GraphQL-Endpunkts mit einer WAF

Eine WAF kann eine zusätzliche Sicherheitsebene gegen bösartige Anwendungsanfragen bieten. Sie sollte kein sicheres GraphQL-Design ersetzen, kann jedoch dazu beitragen, zu verhindern, dass Angriffe anfällige Anwendungskomponenten erreichen.

12. Überwachung des GraphQL-Traffics

Tracken Sie Anfrageraten, Fehler, Authentifizierungsfehler, Betriebsmuster, Query-Komplexität, Backend-Latenz und Ressourcenverbrauch. Eine effektive Observability erleichtert es, Angriffe und Performanceprobleme zu identifizieren, bevor sie sich erheblich auf die Nutzer auswirken.

Wer benötigt GraphQL-API-Sicherheit?

Jede Organisation, die GraphQL-APIs bereitstellt, sollte angemessene Sicherheitskontrollen implementieren. Besonders wichtig wird dies allerdings bei APIs, die sensible Daten, große Traffic-Volumen oder wertvolle Betriebsabläufe verarbeiten.

SaaS-Anbieter

GraphQL kann es Frontend-Anwendungen ermöglichen, komplexe Kunden- und Anwendungsdaten effizient abzurufen. Eine starke Autorisierung ist in mandantenfähigen Umgebungen unerlässlich, um zu verhindern, dass Daten Kundengrenzen überschreiten.

E-Commerce-Unternehmen

GraphQL-APIs können Produktkataloge, Kunden-Accounts, Warenkörbe, Inventar, Checkout-Funktionen und andere hochwertige Vorgänge bereitstellen. Diese APIs können Scraping, Angriffe auf Anmeldeinformationen, Betrug und Verfügbarkeitsangriffe anziehen.

Finanzdienstleistungen

APIs, die Finanz- oder personenbezogene Daten verarbeiten, erfordern eine starke Authentifizierung, Autorisierung, Überwachung und Missbrauchsprävention.

Medien- und Publishing-Unternehmen

GraphQL kann flexiblen Zugriff auf große Inhaltsbibliotheken bieten, kann aber auch zum Ziel für unbefugtes Scraping und ressourcenintensive Querys werden.

Entwickler von Anwendungen, unter anderem für Mobilgeräte

GraphQL ist nützlich, wenn verschiedene Clients unterschiedliche Teilmengen von Daten benötigen. Apps für Mobilgeräte kommunizieren weiterhin mit öffentlich erreichbaren APIs, sodass ein Angreifer potenziell direkt mit der API interagieren kann, anstatt die offizielle App zu verwenden.

Unternehmen, die Microservices nutzen

GraphQL kann einen einheitlichen API-Layer über mehrere Backend-Services bereitstellen. Das macht die Sicherheit besonders wichtig, da eine einzige GraphQL-Schnittstelle Zugriff auf Daten und Funktionen bieten kann, die über zahlreiche interne Systeme verteilt sind.

Wie kann Fastly dabei helfen, GraphQL-APIs zu schützen?

Fastly bietet mehrere Sicherheitsfunktionen, die die in einer GraphQL-Anwendung implementierten Kontrollen ergänzen können.

Fastly Next-Gen WAF

Die Fastly Next-Gen WAF schützt Webanwendungen und APIs vor bösartigen Anfragen. Sie nutzt die SmartParse Erkennungstechnologie von Fastly, um Anfrageparameter zu analysieren und bösartiges Anwendungsverhalten zu identifizieren, anstatt sich ausschließlich auf herkömmlichen Musterabgleich zu verlassen.

Dies kann eine zusätzliche Schutzschicht gegen Injection und Anwendungs-Layer-Angriffe bieten, die auf GraphQL-APIs abzielen.

Fastly API-Sicherheitsfunktionen

Die Funktionen von Fastly für Webanwendungs- und API-Schutz können Unternehmen dabei helfen, APIs zusammen mit herkömmlichen Webanwendungen zu schützen. Die Bereitstellung von Sicherheit auf der Edge ermöglicht es, bösartige Anfragen zu überprüfen, bevor sie Ressourcen von GraphQL-Apps, Datenbanken oder Backend-Services beanspruchen.

Dies ist besonders nützlich in GraphQL-Architekturen, bei denen eine einzige Anfrage potenziell erhebliche nachgelagerte Arbeiten auslösen kann.

Fastly Bot Management

Eine GraphQL-Anfrage muss keine Sicherheitslücke instrumentalisieren, um Schaden anzurichten. Angreifer können automatisierte Clients nutzen, um Daten zu scrapen, Schemas und Vorgänge zu untersuchen, Account-Angriffe zu versuchen oder kostspielige Querys wiederholt auszuführen.

Fastly Bot Management hilft dabei, automatisierten Traffic zu identifizieren und zu verwalten, sodass Unternehmen geeignete Kontrollen für unerwünschte Bots anwenden können, während der Zugriff für legitime Nutzer und genehmigte Automatisierungen erhalten bleibt.

Rate Limiting

Die Rate Limiting-Funktionen von Fastly können helfen, übermäßigen Traffic zu kontrollieren, bevor er die geschützte Anwendung erreicht. Für GraphQL-Umgebungen kann Edge Rate Limiting Kontrollen auf Anwendungsebene wie die Query-Kostenanalyse ergänzen. Die Edge kann übermäßige Anfrageaktivität einschränken, während der GraphQL-Server detailliertere Richtlinien basierend auf den tatsächlichen Kosten und Autorisierungsanforderungen jeder Operation anwendet.

Fastly DDoS Protection

GraphQL-Endpunkte können Ziel von DDoS-Angriffen auf dem Anwendungs-Layer werden, insbesondere wenn Angreifer Querys identifizieren, die unverhältnismäßig viele Backend-Ressourcen verbrauchen. Fastly DDoS Protection kann dabei helfen, bösartigen Traffic auf der Edge zu erkennen und abzuwehren, wodurch sich die Menge an Angriffstraffic reduziert, die die Anwendungsinfrastruktur erreicht.

Edge Delivery und Caching

Wenn GraphQL-Antworten sicher cachefähig sind, können die Auslieferungsfunktionen von Fastly wiederholte Anfragen an die GraphQL-Infrastruktur reduzieren. Das Cachen von GraphQL erfordert eine sorgfältige Planung, da Antworten von Querys, Variablen, Authentifizierung und nutzerspezifischen Daten abhängen können. Unternehmen sollten Antworten nur dann cachen, wenn Cache-Keys und -Richtlinien diese Variationen präzise abbilden.

Bei richtiger Implementierung kann Edge-Caching Backend-Anfragen reduzieren und die API-Performance verbessern.

Echtzeittransparenz

Fastly bietet Echtzeit-Logging und Sicherheitstransparenz, die Teams dabei helfen können, verdächtige API-Aktivitäten zu untersuchen. Für GraphQL-Deployments kann dies die Observability auf Anwendungsebene ergänzen, indem es Sicherheits- und Betriebsteams Transparenz über den Traffic verschafft, bevor dieser den GraphQL-Service erreicht.

Wie fügt sich Fastly in eine GraphQL-Sicherheitsstrategie ein?

Fastly ist am besten als zusätzlicher Sicherheits-Layer um eine ordnungsgemäß abgesicherte GraphQL-Anwendung zu betrachten – nicht als Ersatz für die Sicherheit innerhalb der GraphQL-Implementierung.

Die Anwendung sollte für Kontrollen verantwortlich bleiben, darunter:

  • Authentifizierung

  • Autorisierung auf Objekt- und Feldebene

  • Query-Tiefenlimits

  • Query-Komplexitäts- oder Kostenanalyse

  • Sichere Resolver-Implementierung

  • Eingabevalidierung

  • Sichere Fehlerbehandlung

  • Angemessene Introspektionsrichtlinien

Fastly kann diese Kontrollen durch Next-Gen WAF, API-Schutz, Bot Management, Rate Limiting, DDoS-Schutz, Edge Delivery und Echtzeittransparenz ergänzen.

Zusammen können diese Layer Unternehmen dabei helfen, bösartige Anfragen zu blockieren, bevor sie die GraphQL-Infrastruktur erreichen, automatisierten Missbrauch zu kontrollieren, die Auswirkungen von Traffic-Überflutungen zu reduzieren, APIs vor Anwendungsangriffen zu schützen und den unnötigen Backend-Ressourcenverbrauch zu begrenzen.

Das zentrale Prinzip der GraphQL-API-Sicherheit besteht darin, die Flexibilität von GraphQL zu wahren, ohne Clients unbegrenzte Kontrolle über App-Ressourcen oder -Daten zu geben. Die Kombination von sicherem GraphQL-Design mit Edge-basiertem App- und API-Schutz kann Unternehmen dabei helfen, dieses Gleichgewicht zu erreichen.


Sind Sie bereit, loszulegen?

Treten Sie noch heute mit uns in Kontakt
Experten kontaktieren