← Dokumentace WAF / rate-limiting-rules

Osvědčené postupy pro Rate limiting

Následující části popisují typické konfigurace omezení frekvence požadavků pro běžné případy použití. Poskytnutá ukázková pravidla můžete kombinovat a přizpůsobit vlastnímu scénáři.

Hlavní případy použití omezení frekvence požadavků jsou následující:

Vynucení podrobného řízení přístupu ke zdrojům. Zahrnuje řízení přístupu na základě kritérií, jako je user agent, IP adresa, referrer, host, země a světový region.
Chránit před credential stuffing a útoky typu Account Takeover.
Omezte počet operací prováděných jednotlivými klienty. Patří sem zabránění stahování dat boty, přístupu k citlivým údajům, hromadnému vytváření nových účtů a programovým nákupům na platformách elektronického obchodu.
Chránit REST API před vyčerpáním prostředků (cílenými útoky DDoS) a prostředky obecně před zneužitím.
Chránit GraphQL API tím, že zabraňuje přetížení serveru a omezuje počet operací.

Vynucování podrobného řízení přístupu

Omezit podle user agenta

Typickým případem použití je omezení rychlosti požadavků prováděných jednotlivými user agenty. Následující ukázkové pravidlo umožňuje mobilní aplikaci provést maximálně 100 požadavků za 10 minut. Můžete také vytvořit samostatné pravidlo, které omezí rychlost pro desktopové prohlížeče.

Nastavení	Hodnota
Kritéria shody	User Agent se rovná `MobileApp`
Výraz	`http.user_agent eq "MobileApp"`
Charakteristiky pro počítání	IP
Frekvence (počet požadavků / období)	100 požadavků / 10 minut
Akce	Managed Challenge

Omezte opakované použití jednoho `cf_clearance` cookie

Poté, co návštěvník úspěšně projde Managed Challenge, Cloudflare vydá cf_clearance cookie k jejich identifikaci jako ověřených. Škodliví aktéři se však mohou pokusit znovu použít nebo sdílet jedinou platnou cf_clearance hodnotu napříč více požadavky nebo zařízeními, aby obešli další výzvy k ověření.

Toto pravidlo omezení frekvence požadavků pomáhá takové zneužívání zmírnit tím, že omezuje počet požadavků se stejným cf_clearance hodnotu během definovaného období. Legitimní lidští uživatelé zůstanou neovlivněni, zatímco automatizované nebo opakovaně přehrávané požadavky používající jediný clearance token budou po překročení prahové hodnoty zablokovány.

Nastavení	Hodnota
Kritéria shody	URI Path equals `/checkout`
Výraz	`http.request.uri.path eq "/checkout"`
Charakteristiky pro počítání	Cookie (`cf_clearance`)
Frekvence (počet požadavků / období)	100 požadavků / 10 minut
Akce	Block

Povolit konkrétní IP adresy nebo ASN

Dalším případem užití při kontrole přístupu ke zdrojům je vyloučení nebo zahrnutí IP adres či čísel autonomních systémů (ASN) v pravidle omezení frekvence požadavků.

Následující ukázkové pravidlo povolí až 10 požadavků za minutu ze stejné adresy IP provádějících GET požadavek na /status, pokud IP adresa návštěvníka není zahrnuta v partner_ips Seznam IP adres.

Nastavení	Hodnota
Kritéria shody	URI Path equals `/status` a Request Method equals `GET` a IP Source Address není v seznamu `partner_ips`
Výraz	`http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips`
Charakteristiky pro počítání	IP
Frekvence (počet požadavků / období)	10 požadavků / 1 minuta
Akce	Managed Challenge

Omezit podle referreru

Některé aplikace přijímají požadavky pocházející z jiných zdrojů (například z reklam odkazujících na stránky třetích stran). Počet požadavků generovaných jednotlivými referenčními stránkami proto můžete chtít omezit kvůli správě kvót nebo aby nedocházelo k nepřímým útokům DDoS.

Nastavení	Hodnota
Kritéria shody	URI Path equals `/status` a Request Method equals `GET`
Výraz	`http.request.uri.path eq "/status" and http.request.method eq "GET"`
Charakteristiky pro počítání	Hlavička (`Referer`) ¹
Frekvence (počet požadavků / období)	100 požadavků / 10 minut
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Omezit podle cílového hostitele

Aplikace SaaS nebo zákazníci používající Cloudflare SSL for SaaS může mít tisíce hostů ve stejné zóně, což znemožňuje vytvářet jednotlivá pravidla pro každý host. Řešením je vytvořit pravidlo rate limiting, které jako charakteristiku pro počítání používá právě host.

Následující ukázkové pravidlo bude sledovat frekvenci požadavků na /login endpoint pro každého hostitele:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/login` a Request Method equals `GET`
Výraz	`http.request.uri.path eq "/login" and http.request.method eq "GET"`
Charakteristiky pro počítání	IP a Host
Frekvence (počet požadavků / období)	10 požadavků / 10 minut
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Ochrana před credential stuffing

Typickým případem použití omezení rychlosti je ochrana přihlašovacího endpointu proti útokům, jako je credential stuffing ↗. Následující příklad obsahuje tři různá pravidla omezení frekvence požadavků se stupňujícími se sankcemi pro klienty, kteří odesílají příliš mnoho požadavků.

Pravidlo č. 1

Nastavení	Hodnota
Kritéria shody	Hostname se rovná `example.com` a URI Path equals `/login` a Request Method equals `POST`
Výraz	`http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"`
Charakteristiky pro počítání	IP
Zvýšit čítač, když	URI Path equals `/login` a Method equals `POST` a Response code is in (401, 403)
Výraz pro počítání	`http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}`
Frekvence (počet požadavků / období)	4 požadavky / 1 minuta
Akce	Managed Challenge

Pravidlo č. 2

Nastavení	Hodnota
Kritéria shody	Hostname se rovná `example.com` a URI Path equals `/login` a Request Method equals `POST`
Výraz	`http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"`
Charakteristiky pro počítání	IP
Zvýšit čítač, když	URI Path equals `/login` a Request Method equals `POST` a Response Status Code is in (401, 403)
Výraz pro počítání	`http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}`
Frekvence (počet požadavků / období)	10 požadavků / 10 minut
Akce	Managed Challenge

Pravidlo č. 3

Nastavení	Hodnota
Kritéria shody	Host se rovná `example.com`
Výraz	`http.host eq "example.com"`
Charakteristiky pro počítání	IP
Zvýšit čítač, když	URI Path equals `/login` a Request Method equals `POST` a Response Status Code is in (401, 403)
Výraz pro počítání	`http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}`
Frekvence (počet požadavků / období)	20 požadavků / 1 hodina
Akce	Blokovat na 1 den

Tato ukázková pravidla vyžadují plán Business nebo vyšší.

Pravidlo č. 1 povoluje až čtyři požadavky za minutu, po jejichž překročení se spustí Managed Challenge. Tato konfigurace dává legitimním zákazníkům několik pokusů na to, aby si vzpomněli na heslo. Pokud automatizovaný aktér odešle více požadavků, tohoto klienta pravděpodobně zablokuje nevyřešená výzva Managed Challenge. Pokud naopak člověk výzvu dostane a úspěšně ji projde ve chvíli, kdy dosáhne limitu frekvence pravidla č. 1, poskytne pravidlo č. 2 další úroveň ochrany a umožní až 10 požadavků během následujících 10 minut. Klientům, kteří překročí i tuto druhou prahovou hodnotu, se uplatní pravidlo č. 3 (nejpřísnější), které klienta zablokuje na jeden den.

Tato tři pravidla mají výraz pro počítání oddělený od výrazu pravidla (nazývaného také mitigační výraz). Když nakonfigurujete samostatný výraz pro počítání, kritéria shody se použijí pouze při spuštění akce. Do výrazu pro počítání můžete zahrnout podmínky založené na stavovém kódu HTTP odpovědi a hlavičkách HTTP odpovědi, čímž omezení frekvence požadavků propojíte s logikou vašeho backendu.

Můžete se také rozhodnout použít dva různé výrazy, počítací výraz a výraz pravidla/zmírnění, k definování:

Požadavky použité k výpočtu frekvence.
Požadavky, u kterých byla skutečně provedena akce.

Pravidlo č. 3 počítá rychlost například s ohledem na POST požadavky na /login který vrátil 401 nebo 403 stavovým kódem HTTP. Po překročení limitu frekvence požadavků ale Cloudflare blokuje každý požadavek na example.com hostitele vygenerovaných stejnou IP adresou. Další informace o výrazech pro počítání naleznete v Výpočet frekvence požadavků.

Chránit koncové body OTP a ověřování

Jednorázová hesla (OTP) a ověřovací endpointy (například /api/otp/validate nebo /account/verify) jsou častým cílem útoků hrubou silou. Tyto koncové body jsou obzvláště citlivé, protože útočníci se pokoušejí o velké množství požadavků s různými kódy, aby uhodli platný OTP.

Při konfiguraci omezení frekvence požadavků pro tyto endpointy postupujte podle těchto pokynů:

Shoda s přesnou cestou URI: Výraz pravidla musí odpovídat cestě, na kterou směřuje útočný provoz. Před vytvořením pravidla cestu ověřte v analytice. Pravidlo zaměřené na /validate/otp nebude odpovídat požadavkům na /api/otp/validate.
Použití počítání založeného na odpovědi: Započítává pouze požadavky, které vracejí chybové odpovědi (například 401 nebo 403), abyste neomezovali frekvenci požadavků u legitimních uživatelů, kteří zadávají platné kódy.
Vhodně vymezte rozsah geografických omezení: Pokud omezujete podle země, ověřte, že útočný provoz pochází ze všech zemí, které pozorujete v analytice, nikoli jen z jedné.

Následující ukázkové pravidlo chrání koncový bod pro ověřování OTP tím, že počítá pouze neúspěšné pokusy:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/api/otp/validate` a Request Method equals `POST`
Výraz	`http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST"`
Charakteristiky pro počítání	IP
Zvýšit čítač, když	URI Path equals `/api/otp/validate` a Request Method equals `POST` a Response Status Code is in (401, 403)
Výraz pro počítání	`http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST" and http.response.code in {401 403}`
Frekvence (počet požadavků / období)	5 požadavků / 1 minuta
Akce	Blokovat na 10 minut

Výše uvedené ukázkové pravidlo vyžaduje plán Business nebo vyšší.

Pokud váš koncový bod OTP vrací 200 pro platné i neplatné kódy (s výsledkem v těle odpovědi) použijte místo toho počítání založené na požadavcích s nižší prahovou hodnotou:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/api/otp/validate` a Request Method equals `POST`
Výraz	`http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST"`
Charakteristiky pro počítání	IP
Frekvence (počet požadavků / období)	10 požadavků / 1 minuta
Akce	Managed Challenge

Omezení počtu operací

Omezení frekvence požadavků můžete použít k omezení počtu operací provedených klientem. Přesná podoba pravidla, které tuto ochranu poskytuje, závisí na vaší aplikaci. Následující příklady se týkají scrapování obsahu ↗ pomocí parametrů řetězce dotazu nebo těla JSON.

Zabránit scrapování obsahu (přes query string)

V tomto příkladu klienti provádějí operace, například vyhledávání cen a přidávání do košíku, na webu elektronického obchodu pomocí různých parametrů řetězce dotazu. Typický požadavek odeslaný klientem by mohl vypadat například takto:

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

Váš bezpečnostní tým by mohl zvážit nastavení limitu na počet vyhledávání cen jedním klientem, aby zabránil botům, kterým se případně podařilo uniknout systému Cloudflare Bot Management, ve scrapování celého katalogu obchodu.

Pravidlo č. 1

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant` a URI Query String contains `action=lookup_price`
Výraz	`http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"`
Charakteristiky pro počítání	IP
Frekvence (počet požadavků / období)	10 požadavků / 2 minuty
Akce	Managed Challenge

Pravidlo č. 2

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant` a URI Query String contains `action=lookup_price`
Výraz	`http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"`
Charakteristiky pro počítání	IP
Frekvence (počet požadavků / období)	20 požadavků / 5 minut
Akce	Block

Tato dvě pravidla omezení frekvence požadavků odpovídají požadavkům provádějícím vybranou akci (v tomto příkladu vyhledání ceny) a používají IP jako počítací charakteristiku. Podobně jako u předchozí /login příklad, tato dvě pravidla pomohou snížit počet falešně pozitivních výsledků v případě vytrvalých, ale legitimních návštěvníků.

Chcete-li omezit vyhledávání na konkrétní product_id pomocí parametru řetězce dotazu, můžete tento konkrétní parametr přidat jako charakteristiku pro počítání, takže se frekvence počítá na základě všech požadavků bez ohledu na klienta. Následující ukázkové pravidlo omezuje počet vyhledávání pro každý product_id na 50 požadavků za 10 sekund.

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant`
Výraz	`http.request.uri.path eq "/merchant"`
Charakteristiky pro počítání	Dotaz (`product_id`)
Frekvence (počet požadavků / období)	50 požadavků / 10 sekund
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Stejný vzor pravidel omezení frekvence požadavků můžete použít k ochraně aplikací, které zpracovávají rezervace a objednávky.

Zabránit scrapování obsahu (přes tělo požadavku)

Uvažujme aplikaci, která zpracovává operaci a její parametry prostřednictvím těla požadavku ve formátu JSON. Například lookup_price operace může vypadat například takto:

POST https://api.store.com/merchant
Cookie: session_id=12345

Body:
{
  "action": "lookup_price",
  "product_id": 215
}

V tomto scénáři byste mohli napsat pravidlo, které omezí počet akcí z jednotlivých relací:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant` a JSON String `action` se rovná `lookup_price`
Výraz	`http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"`
Charakteristiky pro počítání	Cookie (`session_id`)
Frekvence (počet požadavků / období)	10 požadavků / 2 minuty
Akce	Managed Challenge

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a kontrolu payloadu.

Můžete také omezit počet vyhledávání každého product_id bez ohledu na klienta, který požadavky odesílá, a to nasazením pravidla, jako je následující:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant` a JSON field `action` se rovná `lookup_price`
Výraz	`http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"`
Charakteristiky pro počítání	JSON field (`product_id`)
Frekvence (počet požadavků / období)	50 požadavků / 10 sekund
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a kontrolu payloadu.

Omezit požadavky od botů

Obecným způsobem, jak identifikovat provoz od botů, je omezit rychlost požadavků, které vyvolávají velké množství 403 nebo 404 stavové kódy odpovědi z původního serveru. To obvykle značí automatizovanou aktivitu z aplikací pro scraping.

V této situaci byste mohli nakonfigurovat pravidlo podobné následujícímu:

Nastavení	Hodnota
Kritéria shody	Hostname se rovná `example.com`
Výraz	`http.host eq "example.com"`
Charakteristiky pro počítání	IP
Zvýšit čítač, když	Response Status Code is in (403, 404)
Výraz pro počítání	`http.response.code in {403 404}`
Frekvence (počet požadavků / období)	5 požadavků / 3 minuty
Akce	Managed Challenge

Toto ukázkové pravidlo vyžaduje plán Business nebo vyšší.

Chcete-li omezit četnost akcí prováděných automatizovanými zdroji, zvažte použití pravidel omezení frekvence požadavků společně s Bot Management. S Bot Management můžete použít bot score jako součást kritérií shody, abyste pravidlo použili pouze na automatizovaný nebo pravděpodobně automatizovaný provoz. Můžete například použít maximální skóre (neboli prahovou hodnotu) 30 pro pravděpodobně automatizovaný provoz a 10 pro automatizovaný provoz.

Pokud vaše aplikace sleduje relace pomocí souboru cookie, můžete tento soubor cookie použít k nastavení kontextu rate limiting, tedy jako počítanou charakteristiku. Nastavením charakteristiky rate limiting na Cookie pravidlo seskupí požadavky z různých IP adres, které ale patří ke stejné relaci, což je běžný scénář při distribuovaném útoku prováděném sítí botů.

Pravidlo č. 1

Nastavení	Hodnota
Kritéria shody	Bot Score menší než 30 a URI Query String obsahuje `action=delete`
Výraz	`cf.bot_management.score lt 30 and http.request.uri.query contains "action=delete"`
Charakteristiky pro počítání	Cookie (`session_id`)
Frekvence (počet požadavků / období)	10 požadavků / 1 minuta
Akce	Managed Challenge

Pravidlo č. 2

Nastavení	Hodnota
Kritéria shody	Bot Score menší než 10 a URI Query String obsahuje `action=delete`
Výraz	`cf.bot_management.score lt 10 and http.request.uri.query contains "action=delete"`
Charakteristiky pro počítání	Cookie (`session_id`)
Frekvence (počet požadavků / období)	20 požadavků / 5 minut
Akce	Block

Tato ukázková pravidla vyžadují Advanced Rate Limiting a Bot Management.

Pokud aplikace nepoužívá cookie relace, můžete použít JA3 fingerprints k identifikaci jednotlivých klientů. JA3 fingerprint je jedinečný identifikátor, dostupný zákazníkům s Bot Management, díky kterému Cloudflare dokáže rozpoznat požadavky pocházející od stejného klienta. Každý klient, ať už automatizovaný, nebo ne, má přiřazený otisk.

Nastavení	Hodnota
Kritéria shody	URI Path equals `/merchant` a Bot Score menší než 10
Výraz	`http.request.uri.path eq "/merchant" and cf.bot_management.score lt 10`
Charakteristiky pro počítání	JA3 Fingerprint
Frekvence (počet požadavků / období)	10 požadavků / 1 minuta
Akce	Managed Challenge

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a Bot Management.

Ochrana REST API

Rozhraní API mohou výrazně zatěžovat backend aplikace, protože zpracování nebo obsloužení požadavků API může být výpočetně náročné. Tyto požadavky navíc mohou vyžadovat složité operace, jako je zpracování dat nebo vyhledávání ve velkých datových sadách, které při zneužití mohou nakonec origin server zcela vyřadit z provozu.

Zabránit objemovým útokům

Advanced Rate Limiting dokáže zmírnit mnoho typů objemových útoků, jako jsou útoky DDoS, mass assignment a exfiltrace dat.

Častým požadavkem je omezit POST akce. U ověřeného provozu můžete použít API Discovery k identifikaci vhodné rychlosti požadavků na jeden endpoint a následně vytvořte pravidlo omezení frekvence požadavků, jako je následující:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/endpoint1` a Request Method equals `POST`
Výraz	`http.request.uri.path eq "/endpoint1" and http.request.method eq "POST"`
Charakteristiky pro počítání	Hlavička (`x-api-key`)
Frekvence (počet požadavků / období)	Podle návrhu API Discovery nebo na základě posouzení analýzou minulého provozu.
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting. API Discovery vyžaduje dodatečnou licenci.

Charakteristikou pro počítání může být libovolná hlavička, klíč, token, soubor cookie, parametr dotazu nebo dokonce pole v těle JSON, protože některá API zahrnují ID relace nebo ID uživatele přímo v těle JSON. Další informace najdete v následujících částech:

Pokud se váš jedinečný identifikátor nachází v cestě URI, přečtěte si Chránit zdroje.
Pokud se váš jedinečný identifikátor nachází v těle JSON, přečtěte si Zabránit scrapování obsahu (přes tělo požadavku).

Chránit zdroje

GET požadavky mohou aplikaci nadměrně zatěžovat nebo ovlivňovat nákladné prostředky, jako je šířka pásma. Uvažujme například aplikaci s velkým množstvím uložených souborů (například obrázků), kde si klienti mohou soubor stáhnout přístupem na jeho konkrétní URL:

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

Pravděpodobně chcete omezit počet stahování, abyste předešli zneužití, ale vzhledem k velikosti datového úložiště nechcete psát jednotlivá pravidla pro každý soubor. V takovém případě můžete napsat pravidlo jako následující:

Nastavení	Hodnota
Kritéria shody	Hostname se rovná `api.example.com` a Request Method equals `GET`
Výraz	`http.host eq "api.example.com" and http.request.method eq "GET"`
Charakteristiky pro počítání	Cesta
Frekvence (počet požadavků / období)	Podle návrhu API Discovery nebo na základě posouzení analýzou minulého provozu.
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Pravidlo definuje limit 10 stažení za 10 minut pro každý soubor v https://api.store.com/files/*. Použitím Path jako charakteristiky pravidla se vyhnete tomu, abyste museli psát nové pravidlo pokaždé, když se nahraje nový soubor s jiným <FILE_ID>. U tohoto pravidla se frekvence počítá u každého požadavku bez ohledu na jeho zdrojovou IP adresu nebo identifikátor relace.

Path můžete také zkombinovat s x-api-key hlavičku (nebo IP adresu, pokud nemáte klíč ani token) k nastavení maximálního počtu stažení, která smí provést konkrétní klient identifikovaný pomocí x-api-key, může provést u daného souboru:

Nastavení	Hodnota
Kritéria shody	Hostname se rovná `api.store.com` a Request Method equals `GET`
Výraz	`http.host eq "api.example.com" and http.request.method eq "GET"`
Charakteristiky pro počítání	Cesta a hlavička (`x-api-key`)
Frekvence (počet požadavků / období)	Podle návrhu API Discovery nebo na základě posouzení analýzou minulého provozu.
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Ochrana GraphQL API

Prevence přetížení serveru u GraphQL API se může lišit od prevence přetížení u RESTful API. Jednou z největších výzev, které přinášejí aplikace postavené na GraphQL, je to, že všechny dotazy na server zpracovává jediná cesta a každý požadavek je obvykle POST operaci. Tím zabráníte tomu, aby se pro různé případy použití API podle metody HTTP a cesty URI používaly odlišné limity četnosti požadavků.

Místo použití metody a cesty jako u RESTful API je ale účel požadavku obvykle vložen do těla, které obsahuje informace o tom, jaká data chce klient načíst nebo změnit (podle Terminologie GraphQL ↗ pro úpravu dat na straně serveru) spolu s veškerými dalšími daty potřebnými k provedení akce.

Chcete-li předejít přetížení serveru, zvažte následující přístupy:

Omezte, kolikrát může konkrétní uživatel volat stejný název operace GraphQL.
Omezte celkovou složitost dotazu, kterou smí daný uživatel požadovat.
Omezte složitost dotazu jednotlivého požadavku.

Následující příklady vycházejí z aplikace, která přijímá recenze filmů. Požadavek GraphQL by mohl vypadat následovně:

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345

Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

Omezte počet operací

Chcete-li omezit četnost akcí, můžete použít následující pravidlo:

Nastavení	Hodnota
Kritéria shody	URI Path equals `/graphql` a Body contains `createReview`
Výraz	`http.request.uri.path eq "/graphql" and http.request.body.raw contains "createReview"`
Charakteristiky pro počítání	Cookie (`session_id`)
Frekvence (počet požadavků / období)	5 požadavků / 1 hodina
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a kontrolu payloadu.

Omezte celkovou složitost dotazu

Složitost potřebná ke zpracování požadavku GraphQL se může výrazně lišit. Protože API používá jediný koncový bod, je obtížné určit složitost jednotlivých požadavků ještě před jejich zpracováním.

Aby byl origin server chráněn před vyčerpáním prostředků, nestačí omezit počet požadavků, ale je třeba omezit míru složitosti potřebnou ke zpracování jednoho klienta za určité období. Cloudflare Rate Limiting umožňuje vytvářet pravidla, která sledovat složitost v průběhu času a blokujte následné požadavky po dosažení rozpočtu složitosti nebo limitu.

Tento typ omezení frekvence požadavků vyžaduje, aby server u každého obslouženého požadavku vypočítal skóre složitosti. Toto skóre pak musí přidat do odpovědi jako hlavičku HTTP. Mechanismus omezení frekvence požadavků následně tuto informaci použije k aktualizaci rozpočtu daného konkrétního klienta.

Následující pravidlo například definuje celkový rozpočet složitosti 1,000 za hodinu:

Nastavení	Hodnota
Kritéria shody	URI Path contains `/graphql`
Výraz	`http.request.uri.path eq "/graphql"`
Charakteristiky pro počítání	Cookie (`session_id`)
Skóre za období	1,000
Období	1 hodina
Název hlavičky odpovědi	`score`
Akce	Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a kontrolu payloadu.

Když origin server zpracuje požadavek, přidá score HTTP hlavičku k odpovědi s hodnotou vyjadřující, kolik práce musel origin server vynaložit na jeho zpracování, například 100. Během následující hodiny může stejný klient odeslat požadavky až do výše dalšího rozpočtu 900. Jakmile je tento rozpočet překročen, další požadavky se blokují, dokud nevyprší časový limit.

Omezte složitost jednotlivého dotazu

Zákazníci s API Shield mohou k ochraně svých GraphQL API použít ochranu proti škodlivým GraphQL dotazům. Ta prohledává váš provoz GraphQL a hledá dotazy, které by mohly přetížit váš origin server a způsobit odepření služby. Můžete vytvořit pravidla, která omezí hloubku a velikost vstupních dotazů GraphQL, a zablokovat tak podezřele velké nebo složité dotazy.

Viz dokumentace API Shield ↗ s dalšími informacemi o ochraně proti škodlivým GraphQL dotazům.

Poznámky pod čarou

Název HTTP hlavičky používá chybný pravopis slova „referrer“. ↩

Osvědčené postupy pro Rate limiting

Vynucování podrobného řízení přístupu

Omezit podle user agenta

Omezte opakované použití jednoho cf_clearance cookie

Povolit konkrétní IP adresy nebo ASN

Omezit podle referreru

Omezit podle cílového hostitele

Ochrana před credential stuffing

Chránit koncové body OTP a ověřování

Omezení počtu operací

Zabránit scrapování obsahu (přes query string)

Zabránit scrapování obsahu (přes tělo požadavku)

Omezit požadavky od botů

Ochrana REST API

Zabránit objemovým útokům

Chránit zdroje

Ochrana GraphQL API

Omezte počet operací

Omezte celkovou složitost dotazu

Omezte složitost jednotlivého dotazu

Poznámky pod čarou

Omezte opakované použití jednoho `cf_clearance` cookie