Bewährte Verfahren zur Ratenbegrenzung

Die folgenden Abschnitte behandeln typische Konfigurationen zur Ratenbegrenzung für gängige Anwendungsfälle. Sie können die bereitgestellten Beispielregeln kombinieren und an Ihr eigenes Szenario anpassen.

Die wichtigsten Anwendungsfälle für die Ratenbegrenzung sind die folgenden:

  • Setzen Sie eine detaillierte Zugriffskontrolle für Ressourcen durch, die eine Zugriffskontrolle auf der Grundlage von Kriterien wie User-Agent, IP-Adresse, Referrer, Host, Land und Weltregion umfasst.
  • Schützen Sie sich vor Credential Stuffing und Account-Übernahme-Angriffen.
  • Begrenzen Sie die Anzahl der von einzelnen Kunden durchgeführten Vorgänge. Umfasst die Verhinderung von Scraping durch Bots, den Zugriff auf sensible Daten, die massenhafte Erstellung neuer Konten und den programmatischen Einkauf auf E-Commerce-Plattformen.
  • Schützen Sie REST-APIs vor Ressourcenerschöpfung (gezielte DDoS Angriffe) und Ressourcen vor Missbrauch im Allgemeinen.
  • Schützen Sie GraphQL APIs, indem Sie eine Überlastung des Servers verhindern und die Anzahl der Vorgänge begrenzen.

Durchsetzung einer granularen Zugriffskontrolle

Sie können die Ratenbegrenzung verwenden, um zu steuern, wie Benutzer und Anwendungen auf Ihre Ressourcen zugreifen. Die Ratenbegrenzung schützt Ihre Anwendung vor Missbrauch, indem sie den Datenverkehr anhand von Attributen wie User-Agent, IP-Adresse, Referrer oder Host einschränkt.

Jedes der folgenden Beispiele zeigt, wie eine Regel zur Ratenbegrenzung für ein bestimmtes Zugriffskontrollszenario konfiguriert wird.

Einschränkung der Anfrage durch den User-Agent

Sie können die Anzahl der Anfragen, die für einen bestimmten User-Agent zulässig sind, einschränken. Das folgende Regelbeispiel erlaubt es Benutzern mobiler Apps, alle 10 Minuten bis zu 100 Anfragen zu stellen. Sie können auch eine separate Regel erstellen, die die Rate für Desktop-Browser begrenzt.

Beispiel – Anfragen nach Benutzeragent begrenzen
Einstellung Wert
Übereinstimmungskriterien User Agent entspricht MobileApp
Ausdruck http.user_agent eq "MobileApp"
Zählmerkmale IP
Rate (Anfragen/Zeitraum) 100 Anfragen / 10 Minuten
Aktion Verwaltete Abfrage

Bestimmte IP-Adressen oder ASNs zulassen

Kontrollieren Sie den Zugriff, indem Sie bestimmte IP-Adressen oder Autonomous System Numbers (ASNs) in eine Rate-Limiting-Regel aufnehmen oder davon ausschließen.

Das folgende Beispiel für eine Rate-Limiting-Regel erlaubt bis zu 10 Anfragen pro Minute von derselben IP-Adresse und eine GET Anfrage an den /status Pfad, vorausgesetzt, die IP-Adresse ist nicht in der IP-Liste mit dem Titel enthalten partner_ips.

Beispiel – Bestimmte IPs oder ASNs zulassen
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /status und Anforderungsmethode entspricht GET und IP-Quelladresse ist nicht in der Liste enthalten partner_ips
Ausdruck http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips
Zählmerkmale IP
Rate (Anfragen/Zeitraum) 10 Anfragen / 1 Minute
Aktion Verwaltete Abfrage

Anfragen nach Referrer begrenzen

Sie können Anfragen einschränken, die von Referrer-Seiten stammen, wie beispielsweise Werbung von Drittanbietern oder externe Websites. Dieser Anwendungsfall trägt dazu bei, das Risiko indirekter Denial-of-Service-Angriffe ( DDoS ) zu verringern, und unterstützt Sie bei der Verwaltung von Anforderungskontingenten.

Beispiel – Anfragen nach Referrer begrenzen
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /status und Anforderungsmethode entspricht GET
Ausdruck http.request.uri.path eq "/status" and http.request.method eq "GET"
Zählmerkmale Header (Referrer). Der HTTP Header-Name verwendet eine falsche Schreibweise von referrer.
Rate (Anfragen/Zeitraum) 100 Anfragen / 10 Minuten
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung.

Schutz vor Credential Stuffing

Sie können die Ratenbegrenzung nutzen, um Anmeldeendpunkte vor Credential-Stuffing-Angriffen zu schützen. Credential Stuffing tritt auf, wenn Angreifer automatisierte Skripte verwenden, um mehrere Kombinationen aus Benutzernamen und Passwörtern in einem Anmeldeformular auszuprobieren. Die Ratenbegrenzung hilft, diese Angriffe abzuwehren, indem sie wiederholte fehlgeschlagene Anmeldeversuche von derselben IP-Adresse einschränkt.

Die folgenden Beispiele zeigen drei Regeln zur Geschwindigkeitsbegrenzung, die die Einschränkungen und Strafen basierend auf der Anzahl der fehlgeschlagenen Anmeldeversuche erhöhen.

Regel 1: Anfängliche Schutzschwelle

Regel 1 erlaubt bis zu vier fehlgeschlagene Anmeldeversuche pro Minute. Wenn das Limit überschritten wird, löst das System eine Managed Challenge aus. Diese Konfiguration hilft legitimen Benutzern, gelegentliche Anmeldefehler zu beheben, und schreckt gleichzeitig automatisierte Bots ab.

Regel 1 Konfiguration
Einstellung Wert
Übereinstimmungskriterien Hostname entspricht example.com und URI-Pfad entspricht /login und Anforderungsmethode entspricht POST
Ausdruck http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Zählmerkmale IP
Zähler erhöhen, wenn URI-Pfad entspricht /login und Methode entspricht POST und Antwortcode liegt zwischen (401, 403)
Zählende Ausdrucksweise http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Rate (Anfragen/Zeitraum) 4 Anfragen / 1 Minute
Aktion Verwaltete Abfrage

Regel 2: Zwischenschutzschwelle

Wenn legitime Benutzer die Herausforderung bestehen, wenn sie das Limit von Regel 1 erreichen, wendet Regel 2 zusätzlichen Schutz für Clients an, die weiterhin fehlgeschlagene Anmeldeversuche unternehmen. Es sind bis zu 10 fehlgeschlagene Versuche innerhalb von 10 Minuten zulässig, bevor eine weitere Managed Challenge ausgelöst wird.

Konfiguration nach Regel 2
Einstellung Wert
Übereinstimmungskriterien Hostname entspricht example.com und URI-Pfad entspricht /login und Anforderungsmethode entspricht POST
Ausdruck http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Zählmerkmale IP
Zähler erhöhen, wenn URI-Pfad entspricht /login und Anforderungsmethode entspricht POST und Antwortstatuscode liegt zwischen (401, 403)
Zählende Ausdrucksweise http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Rate (Anfragen/Zeitraum) 10 Anfragen / 10 Minuten
Aktion Verwaltete Abfrage

Regel 3: Strenge Schutzschwelle

Regel 3 sieht eine strengere Strafe für Kunden vor, die den in Regel 2 festgelegten Schwellenwert überschreiten, indem eine IP-Adresse nach 20 fehlgeschlagenen Anmeldeversuchen innerhalb einer Stunde für einen Tag gesperrt wird. Diese Regel bietet einen letzten Schutz gegen hartnäckige Angriffsversuche.

Konfiguration nach Regel 3
Einstellung Wert
Übereinstimmungskriterien Host entspricht example.com
Ausdruck http.host eq "example.com"
Zählmerkmale IP
Zähler erhöhen, wenn URI-Pfad entspricht /login und Anforderungsmethode entspricht POST und Antwortstatuscode liegt zwischen (401, 403)
Zählende Ausdrucksweise http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Rate (Anfragen/Zeitraum) 20 Anfragen / 1 Stunde
Aktion 1 Tag sperren

Für alle diese Beispielregeln ist ein Business-Tarif oder höher erforderlich.

Diese drei Regeln haben einen Zähl-Ausdruck, der vom Regelausdruck (auch als Mitigationsausdruck bezeichnet) getrennt ist. Wenn Sie einen separaten Zählausdruck konfigurieren, wird das Übereinstimmungskriterium verwendet, wenn eine Aktion ausgelöst wird. In der Zählformel können Sie Bedingungen basierend auf dem HTTP Antwortstatuscode und HTTP den Antwort-Headern einfügen, um die Ratenbegrenzung in Ihre Backend-Logik zu integrieren.

Sie können sich auch für zwei verschiedene Ausdrücke entscheiden: einen Zählausdruck und einen Regel-/Minderungsausdruck – zu definieren:

  1. Die Anfragen, die zur Berechnung des Satzes verwendet wurden.
  2. Die tatsächlich bearbeiteten Anfragen.

Beispielsweise berechnet Regel 3 die Rate unter Berücksichtigung von POST Anfragen, /login die einen 401 Statuscode 403HTTP oder zurückgegeben haben. Wenn jedoch das Limit überschritten wird, CIS werden alle Anfragen an den example.com Host, die von derselben IP-Adresse generiert werden, blockiert.

Begrenzung der Anzahl der Operationen

Mit der Ratenbegrenzung können Sie steuern, wie viele Vorgänge ein Client innerhalb eines bestimmten Zeitraums ausführt. Die von Ihnen konfigurierten Regeln hängen vom Verhalten Ihrer Anwendung und vom Risikoprofil ab.

Die folgenden Beispiele zeigen, wie Sie Content Scraping und automatisierte Aktivitäten verhindern können, die Ihr System überlasten oder Ihre Daten missbrauchen können. Beispiele hierfür sind die Begrenzung von Anfragen durch Abfragezeichenfolgen, JSON-Body-Parameter oder Bot-Eigenschaften.

Verhindern von Content-Scraping durch Verwendung von Abfragezeichenfolgen

In diesem Beispiel führen Kunden über Query-String-Parameter Operationen (wie Preisabfragen oder das Hinzufügen von Artikeln zu einem Warenkorb) auf einer E-Commerce-Website durch. Eine typische Anfrage, die von einem Client gesendet wird, könnte beispielsweise wie folgt aussehen:

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

Ihr Sicherheitsteam sollte möglicherweise in Betracht ziehen, eine Begrenzung für die Anzahl der Preisabfragen durch einen Kunden festzulegen, um zu verhindern, dass Bots – die möglicherweise dem Bot-Management CIS entgangen sind – den gesamten Katalog des Shops scrapen.

Regel 1 Konfiguration
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant und URI-Abfragezeichenfolge enthält action=lookup_price
Ausdruck http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Zählmerkmale IP
Rate (Anfragen/Zeitraum) 10 Anfragen / 2 Minuten
Aktion Verwaltete Abfrage
Konfiguration nach Regel 2
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant und URI-Abfragezeichenfolge enthält action=lookup_price
Ausdruck http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Zählmerkmale IP
Rate (Anfragen/Zeitraum) 20 Anfragen / 5 Minuten
Aktion Block

Diese beiden Regeln zur Begrenzung der Rate gleichen Anfragen ab, die eine ausgewählte Aktion ausführen (in diesem Beispiel die Preisanfrage), und verwenden IP als Zählmerkmal. Ähnlich wie beim Beispiel /login tragen die beiden Regeln dazu bei, Fehlalarme bei wiederkehrenden (aber legitimen) Besuchern zu reduzieren.

Sie können die Suche nach einem bestimmten Element product_id einschränken, indem Sie einen Abfragezeichenfolgenparameter verwenden. Durch Hinzufügen eines Abfrageparameters als Zählmerkmal wird die Rate über alle Anfragen hinweg berechnet, unabhängig vom Client.

Das folgende Beispiel begrenzt die Anzahl der Suchvorgänge für jedes product_id auf 50 Anfragen in 10 Sekunden.

Regelbegrenzung über Abfragezeichenfolge
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant
Ausdruck http.request.uri.path eq "/merchant"
Zählmerkmale Abfrage (product_id)
Rate (Anfragen/Zeitraum) 20 Anfragen / 10 Sekunden
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung.

Sie können dasselbe Muster von Regeln zur Ratenbegrenzung anwenden, um Anwendungen zu schützen, die Reservierungen und Buchungen verarbeiten.

Verhindern von Content-Scraping durch Verwendung des Request-Body

Betrachten Sie eine Anwendung, die den Vorgang und seine Parameter über den Request Body im JSON-Format verarbeitet. Beispielsweise könnte der Vorgang lookup_price wie folgt aussehen:

POST https://api.store.com/merchant
Cookie: session_id=12345
Body:
{
  "action": "lookup_price",
  "product_id": 215
}

In diesem Szenario können Sie die folgende Regel erstellen, um die Anzahl der Aktionen aus einzelnen Sitzungen zu begrenzen:

Regel – Suchvorgänge pro Sitzung begrenzen
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant und JSON-Zeichenfolge action entspricht lookup_price
Ausdruck http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Zählmerkmale Keks (session_id)
Rate (Anfragen/Zeitraum) 10 Anfragen / 2 Minuten
Aktion Verwaltete Abfrage

Diese Beispielregel erfordert erweiterte Ratenbegrenzung und Nutzlastprüfung.

Sie können auch die Anzahl der Suchvorgänge für jeden product_id unabhängig vom Client, der die Anfragen stellt, begrenzen, indem Sie eine Regel wie die folgende implementieren:

Regel – Suchanfragen pro Produkt-ID begrenzen
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant und JSON-Feld action entspricht lookup_price
Ausdruck http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Zählmerkmale JSON-Feld (product_id)
Rate (Anfragen/Zeitraum) 50 Anfragen / 10 Sekunden
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung und Nutzlastprüfung.

Wenn der Request-Body nicht im JSON-Format vorliegt, können Sie das http.request.body.raw Feld und reguläre Ausdrücke (zusammen mit dem Operator „matches“ ) verwenden, um dasselbe Ziel zu erreichen.

Anfragen von Bots einschränken

Sie können die Ratenbegrenzung verwenden, um den automatisierten Datenverkehr von Bots zu kontrollieren. Ein gängiger Ansatz besteht darin, Anfragen zu überwachen, die eine hohe Anzahl von 403 oder 404 Antwortstatuscodes zurückgeben, die häufig auf automatisierte Scraping-Aktivitäten hinweisen.

In dieser Situation könnten Sie eine Regel ähnlich der folgenden konfigurieren:

Regel – Anfragen basierend auf Antwortstatuscodes begrenzen
Einstellung Wert
Übereinstimmungskriterien Hostname entspricht example.com
Ausdruck http.host eq "example.com"
Zählmerkmale IP
Zähler erhöhen, wenn Der Antwortstatuscode liegt zwischen (401, 403)
Zählende Ausdrucksweise http.response.code in {401 403}
Rate (Anfragen/Zeitraum) 5 Anfragen / 3 Minuten
Aktion Verwaltete Abfrage

Für diese Beispielregel ist ein Business-Tarif oder höher erforderlich.

Um die Häufigkeit der von automatisierten Quellen ausgeführten Aktionen zu steuern, sollten Sie Regeln zur Begrenzung der Nutzungsrate in Verbindung mit dem Bot-Management in Betracht ziehen. Mit Bot Management können Sie den Bot-Score als Teil der Übereinstimmungskriterien verwenden, um die Regel nur auf automatisierten oder wahrscheinlich automatisierten Datenverkehr anzuwenden. Beispielsweise können Sie eine maximale Punktzahl (oder Schwelle) von 30 für wahrscheinlichen automatisierten Traffic und 10 für automatisierten Traffic verwenden.

Sie können den Schutz verbessern, indem Sie die Ratenbegrenzung mit Bot-Management kombinieren. Mit Bot Management können Sie den Bot-Score als Teil der Übereinstimmungskriterien verwenden, um die Regel nur auf automatisierten oder wahrscheinlich automatisierten Datenverkehr anzuwenden.

Zum Beispiel:

  • Ein Bot-Score unter 30 weist auf wahrscheinlich automatisierten Traffic hin.
  • Ein Bot-Score unter 10 steht für bestätigten automatisierten Traffic.

Begrenzung der Anfragen pro Sitzung

Wenn Ihre Anwendung Sitzungscookies verwendet, verwenden Sie das Cookie als Zählmerkmal. Diese Methode gruppiert Anfragen von verschiedenen IP-Adressen innerhalb derselben Sitzung – nützlich für die Erkennung verteilter Bot-Angriffe.

Regel 1

Anfrage für Bot-Score unter 30 begrenzen
Einstellung Wert
Übereinstimmungskriterien Bot-Score unter 30 und URI-Abfragezeichenfolge enthält action=delete
Ausdruck cis.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
Zählmerkmale Keks (session_id)
Rate (Anfragen/Zeitraum) 10 Anfragen / 1 Minute
Aktion Verwaltete Abfrage

Regel 2

Anfrage für Bot-Score unter 10 begrenzen
Einstellung Wert
Übereinstimmungskriterien Bot-Score unter 10 und URI-Abfragezeichenfolge enthält action=delete
Ausdruck cis.bot_management.score lt 10 and http.request.uri.query contains "action=delete"
Zählmerkmale Keks (session_id)
Rate (Anfragen/Zeitraum) 20 Anfragen / 5 Minuten
Aktion Block

Diese Beispielregeln erfordern erweiterte Ratenbegrenzung und Bot-Management.

Verwendung von JA3 Fingerabdrücken

Wenn die Anwendung kein Session-Cookie verwendet, können Sie Fingerabdrücke JA3 verwenden, um einzelne Clients zu identifizieren. Ein JA3 Fingerabdruck ist eine eindeutige Kennung, die Kunden mit Bot-Management zur Verfügung steht und die es ermöglicht CIS, Anfragen desselben Clients zu identifizieren. Alle Clients haben einen zugehörigen Fingerabdruck, unabhängig davon, ob sie automatisiert sind oder nicht.

Anfrage durch Verwendung von JA3 Fingerabdruck begrenzen
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /merchant und Bot-Score kleiner als 10
Ausdruck http.request.uri.path eq "/merchant" and cf.bot_management.score lt 10
Zählmerkmale JA3 Fingerabdruck
Rate (Anfragen/Zeitraum) 10 Anfragen / 1 Minute
Aktion Verwaltete Abfrage

Diese Beispielregel erfordert erweiterte Ratenbegrenzung und Bot-Verwaltung.

Schutz von REST-APIs

REST-APIs können eine hohe Belastung für Backend-Systeme darstellen, da API-Anfragen oft eine intensive Verarbeitung oder umfangreiche Datenabfragen erfordern. Unkontrollierter API-Zugriff kann zu Leistungseinbußen oder sogar Ausfallzeiten führen. Verwenden Sie erweiterte Ratenbegrenzung, um Missbrauch zu verhindern, volumetrische Angriffe abzuwehren und kritische Ressourcen zu schützen.

Ressourcen schützen

Selbst GET Anfragen können die Anwendung belasten oder Bandbreite verbrauchen, wenn sie für das Herunterladen großer Datenmengen wie Dateien oder Bilder verwendet werden.

Betrachten Sie beispielsweise den folgenden Endpunkt:

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

Um Missbrauch zu verhindern und gleichzeitig legitime Downloads zuzulassen, können Sie eine Regel definieren, die Dateianfragen begrenzt, ohne für jede Datei separate Regeln schreiben zu müssen.

Regel – Datei-Downloads nach Pfad begrenzen
Einstellung Wert
Übereinstimmungskriterien Hostname entspricht api.example.com und Anforderungsmethode entspricht GET
Ausdruck http.host eq "api.example.com" and http.request.method eq "GET"
Zählmerkmale Pfad
Rate (Anfragen/Zeitraum) Wie von API Discovery vorgeschlagen oder durch Analyse des bisherigen Datenverkehrs bewertet.
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung.

Diese Regel begrenzt Downloads auf 10 Anfragen pro 10 Minuten pro Datei unter https://api.store.com/files/*. Durch die Verwendung von „Pfad“ als Zählmerkmal können Sie vermeiden, für jedes neue <FILE_ID> Element neue Regeln zu erstellen. Der Preis wird pro Datei berechnet, unabhängig von der IP-Adresse des Kunden oder der Sitzungs-ID.

Sie können den Schutz weiter verstärken, indem Sie mit einer Client-Kennung Path wie x-api-key oder IP kombinieren. Mit diesem Ansatz können Sie die Anzahl der Downloads begrenzen, die ein bestimmter Client für eine bestimmte Datei durchführen kann.

Regel – Dateidownloads nach Pfad und Header begrenzen
Einstellung Wert
Übereinstimmungskriterien Hostname entspricht api.store.com und Anforderungsmethode entspricht GET
Ausdruck http.host eq "api.example.com" and http.request.method eq "GET"
Zählmerkmale Pfad und Kopfzeile (x-api-key)
Rate (Anfragen/Zeitraum) Wie von API Discovery vorgeschlagen oder durch Analyse des bisherigen Datenverkehrs bewertet.
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung.

Schutz von GraphQL APIs

Die Vermeidung einer Serverüberlastung für GraphQL APIs kann sich von der Vermeidung einer Überlastung für RESTful-APIs unterscheiden. Eine der größten Herausforderungen bei Anwendungen, die auf aufbauen, besteht GraphQL darin, dass ein einziger Pfad alle Abfragen an den Server verwaltet und jede Anfrage in der Regel eine POST Operation ist. Dadurch wird verhindert, dass unterschiedliche Ratenbegrenzungen für verschiedene APIs basierend auf der HTTP Methode und dem URI-Pfad erstellt werden.

Anstatt jedoch die Methode und den Pfad wie bei einer RESTful-API zu verwenden, ist der Zweck der Anfrage in der Regel im Hauptteil eingebettet, der Informationen darüber enthält, welche Daten der Client abrufen oder mutieren möchte (gemäß GraphQL's der Terminologie für die serverseitige Datenänderung), zusammen mit allen zusätzlichen Daten, die zur Ausführung der Aktion erforderlich sind.

Um eine Überlastung des Servers zu vermeiden, sollten Sie die folgenden Ansätze in Betracht ziehen:

  • Begrenzen Sie die Anzahl der Aufrufe desselben GraphQL Operationsnamens durch einen bestimmten Benutzer.
  • Begrenzen Sie die Gesamtkomplexität der Abfragen, die ein bestimmter Benutzer anfordern darf.
  • Begrenzen Sie die Komplexität der Abfrage jeder einzelnen Anfrage.

Die folgenden Beispiele basieren auf einer Anwendung, die Bewertungen für Filme akzeptiert.

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345
Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

Begrenzung der Anzahl der Operationen

Um die Häufigkeit von Aktionen zu begrenzen, erstellen Sie die folgende Regel:

Begrenzen Sie die Anzahl der Vorgänge
Einstellung Wert
Übereinstimmungskriterien URI-Pfad entspricht /graphql und Body enthält createReview
Ausdruck http.request.uri.path eq "/graphql" and http.request.body.raw contains "createReview"
Zählmerkmale Keks (session_id)
Rate (Anfragen/Zeitraum) 5 Anfragen / 1 Stunde
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung und Nutzlastprüfung.

Begrenzung der Gesamtkomplexität von Abfragen

Die Komplexität der Bearbeitung einer GraphQL Anfrage kann erheblich variieren. Da die API einen einzigen Endpunkt verwendet, kann es schwierig sein, die Komplexität jeder Anfrage vor ihrer Verarbeitung zu bestimmen.

Um eine Erschöpfung der Ressourcen auf dem Ursprungsserver zu verhindern, sollten Sie die Gesamtkomplexität der Anfragen pro Client im Zeitverlauf begrenzen, anstatt die Anzahl der Anfragen zu begrenzen. CIS Mit Rate Limiting können Sie Regeln erstellen, die die Komplexität im Zeitverlauf verfolgen und Anfragen blockieren, die ein definiertes Komplexitätsbudget überschreiten.

Bei dieser Methode muss der Ursprungsserver jeder Anfrage einen Komplexitätswert zuweisen und diesen Wert in den HTTP Antwort-Header aufnehmen. Der ratenbegrenzende Mechanismus verwendet dann die Score-Informationen, um das Komplexitätsbudget für diesen bestimmten Client zu aktualisieren.

Das folgende Beispiel definiert ein Gesamtkomplexitätsbudget von 1.000 pro Stunde:

Begrenzen Sie die Gesamtkomplexität der Abfrage.
Einstellung Wert
Übereinstimmungskriterien URI-Pfad enthält /graphql
Ausdruck http.request.uri.path eq "/graphql"
Zählmerkmale Keks (session_id)
Punktestand pro Spielabschnitt 1.000
Punkt 1 Stunde
Name des Antwort-Headers score
Aktion Block

Diese Beispielregel erfordert erweiterte Ratenbegrenzung und Nutzlastprüfung.

Wenn der Ursprungsserver eine Anfrage verarbeitet, fügt er der Antwort einen scoreHTTP Header hinzu, dessen Wert angibt, wie viel Arbeit der Ursprungsserver zur Bearbeitung der Anfrage aufgewendet hat. Beispiel: 100. In der nächsten Stunde kann derselbe Kunde Anfragen bis zu einem zusätzlichen Budget von 900. Sobald dieses Budget überschritten wird, werden spätere Anfragen bis zum Ablauf der Zeitüberschreitung blockiert.

Begrenzung der Komplexität einzelner Abfragen

API Shield-Kunden können den Schutz vor bösartigen GraphQL Abfragen nutzen, um ihre GraphQL APIs zu schützen. Diese Funktion scannt den eingehenden GraphQL Datenverkehr nach Anfragen, die den Ursprungsserver überlasten und einen Denial-of-Service-Zustand verursachen könnten.

Sie können Regeln erstellen, um die Tiefe und Größe eingehender GraphQL Abfragen zu begrenzen. Diese Regeln helfen dabei, verdächtige oder übermäßig komplexe Abfragen zu blockieren, bevor sie sich auf die Leistung auswirken.