← Všechny produkty

Web Application Firewall (WAF)

Cloudflare WAF vyhodnocuje HTTP požadavky procházející přes proxy oproti vlastním pravidlům, pravidlům omezení frekvence požadavků a spravovaným sadám pravidel Cloudflare, než je přepošle na origin server. Tato stránka popisuje model vyhodnocování, konfigurační objekty, dokumentované limity, dostupnost podle tarifu a postup nasazení.

Řízení dokumentu

Dana
Technická redaktorka, Integrity Czech Republic s.r.o.

Přehled

Web application firewall kontroluje HTTP požadavky ještě předtím, než je zpracuje aplikace, a uplatňuje pravidla, která je povolují, zaznamenávají, prověřují, přesměrovávají nebo blokují. Jde o filtrovací kontrolu, která funguje souběžně s opravou chyb, nikoli místo ní: snižuje expozici vůči známým třídám zneužití a automatizovanému skenování v období mezi zveřejněním zranitelnosti a nasazením opravy.

Cloudflare WAF se vyhodnocuje v datacentrech Cloudflare, která pro danou zónu zajišťují proxy provoz. Cloudflare uvádí, že jeho síť funguje ve 348 městech (https://www.cloudflare.com/network/, získáno 28. 8. 2026). Kontroluje se pouze provoz, který je proxovaný přes Cloudflare. WAF obchází záznam typu DNS only, hostitelský název přeložený mimo zónu nebo klient, který se připojuje přímo na IP adresu origin serveru.

Obsah pravidel ve spravovaných sadách pravidel Cloudflare spravuje Cloudflare a mění se bez nutnosti nasazení ze strany zákazníka. Cloudflare nezveřejňuje smluvní interval aktualizací obsahu spravovaných pravidel, proto je frekvence aktualizací zde popsána jako proces řízený dodavatelem, nikoli jako závazek týkající se doby reakce.

Latenci přidanou vyhodnocením pravidla Cloudflare nezveřejňuje jako naměřenou hodnotu pro danou konfiguraci. Z tohoto důvodu tato stránka neuvádí žádné číslo latence. Pokud je latence pro váš návrh důležitým parametrem, změřte ji na vlastní konfiguraci.

Architektura

Požadavek na hostname za proxy Cloudflare ukončuje TLS v datacentru Cloudflare, které je vybráno pomocí anycast routingu. Požadavek poté prochází přes ruleset engine, který vyhodnocuje pravidla seskupená do seřazených fází. Bezpečnostně relevantní fáze se provádějí v tomto pořadí:

1. Normalizace URL a sanitizace požadavků.
2. http_request_firewall_custom: vlastní pravidla zóny a účtu.
3. http_ratelimit: pravidla omezení rychlosti.
4. http_request_firewall_managed: Cloudflare Managed Ruleset, Cloudflare OWASP Core Ruleset a další spravované sady pravidel nasazené v zóně.

V rámci fáze se pravidla vyhodnocují v nakonfigurovaném pořadí. Terminační akce zastaví vyhodnocování zbývajících pravidel pro daný požadavek. Neukončující akce umožňuje pokračovat ve vyhodnocování. Úplný seznam fází, včetně fází transform, redirect a cache, je zdokumentován v referenci fází uvedené níže.

Detekce jsou oddělené od pravidel. Attack score, detekce uniklých přihlašovacích údajů, kontrola škodlivých nahrávaných souborů a detekce citlivých dat počítají hodnoty během zpracování požadavku a zpřístupňují je jako pole. Samy o sobě provoz neblokují, pravidlo musí dané pole odkazovat a určit akci. Právě proto povolení detekce nezmění žádný provoz, dokud ji nezačne využívat nějaké pravidlo.

Cloudflare Managed Ruleset používá signaturní a heuristické detekce sestavené Cloudflare. OWASP Core Ruleset funguje jinak: vyhodnocuje požadavek proti obecným vzorům útoků, akumuluje skóre a spustí se, jakmile skóre překročí nakonfigurovanou prahovou hodnotu na nakonfigurované úrovni paranoia level. Obě sady pravidel se ladí nezávisle na sobě.

Možnosti

Model konfigurace

Konfigurace WAF se skládá ze sad pravidel nasazených do fází. Pravidlo má výraz, akci, pořadí a volitelné parametry akce. Výrazy se zapisují v jazyce Cloudflare Rules nad typovanými poli, jako je http.request.uri.path, http.request.headers, ip.src.country, ip.src.asnum, cf.bot_management.score a cf.waf.score. Dostupnost polí se liší podle plánu; pole se skóre botů a útoků vyžadují odpovídající oprávnění.

Ve fázích firewallu jsou k dispozici tyto akce: Block, Managed Challenge, Interactive Challenge, JS Challenge, Redirect, Serve Error, Skip, Execute a Log. Chování spravované sady pravidel se neupravuje editací pravidel dodavatele, ale pomocí přepsání: přepsání na úrovni sady pravidel mění akci nebo stav celé sady pravidel, přepsání podle štítků mění skupinu pravidel a přepsání na úrovni pravidla mění jedno konkrétní pravidlo. Výjimky, označované také jako pravidla přeskočení, vyřazují konkrétní provoz z vyhodnocování spravované sady pravidel, aniž by pravidla deaktivovaly globálně.

U OWASP Core Ruleset určují chování dvě nastavení: paranoia level, který určuje, kolik pravidel se podílí na skórování, a prahová hodnota skóre, která stanovuje skóre anomálie, při kterém sada pravidel zasáhne. Zvýšení paranoia level zvyšuje jak míru detekce, tak míru falešně pozitivních výsledků.

Konfiguraci lze spravovat prostřednictvím dashboardu, Rulesets API a Cloudflare Terraform provider. Pořadí pravidel a pořadí nasazení sad pravidel jsou součástí konfigurace a měly by být uložena v systému správy verzí, pokud pravidla spravujete jako kód.

Limity a omezení

Níže uvedené hodnoty byly ověřeny podle dokumentace Cloudflare ke dni 2026-08-31 a mohou se bez upozornění změnit. Než se na ně při návrhu budete spoléhat, ověřte si je u zdroje: vlastní pravidla, pravidla rate limitingu a akce jazyka Rules.

Upozorňujeme, že charakteristiky počítání dostupné v plánu Pro jsou stejné jako v plánu Free. Pravidlo rate limitingu, které počítá podle čehokoli jiného než zdrojové adresy, vyžaduje plán Business nebo Enterprise, což je častá příčina toho, že pravidlo navržené v jednom plánu nelze nasadit v jiném.

Další omezení, která platí bez ohledu na plán:

• Kontroluje se pouze provoz procházející přes proxy. Záznamy typu DNS only, přímá připojení na IP adresu origin serveru a protokoly mimo HTTP nejsou součástí datové cesty WAF.
• Kontrola těla požadavku je omezena maximální kontrolovanou velikostí těla požadavku; obsah nad touto hranicí se nevyhodnocuje. Aktuální hodnotu si ověřte ve zdrojové dokumentaci.
• Obsah spravovaných pravidel je pod kontrolou dodavatele. Jednotlivá spravovaná pravidla lze deaktivovat nebo přepsat jejich chování, samotná pravidla ale nelze upravovat.
• Detekce samy o sobě nic neprovádí. Povolení attack score, detekce uniklých přihlašovacích údajů nebo kontroly nahrávaných souborů nezmění žádný provoz, dokud na výsledné pole neodkáže nějaké pravidlo.
• Vzorkování a uchovávání analytických dat se liší podle plánu, což ovlivňuje množství podkladů dostupných pro ladění u nižších plánů.

Dostupnost podle tarifu

Nasazení

Předpoklady. Než začnete měnit jakékoli pravidlo, dokončete následující:

• Zmapujte aplikace, frameworky, vystavené koncové body a cesty API obsluhované danou zónou, včetně administrativních rozhraní a koncových bodů pro komunikaci mezi stroji.
• Zaznamenejte si, které hostname jsou proxované a které jsou DNS-only.
• Identifikujte integrace, které nesmí být vystaveny výzvě ani blokovány: monitorovací sondy, platební callbacky, partnerské systémy, CI pipeline a mobilní klienty.
• Potvrďte, na jakém plánu zóna je, protože Log akce a na tom závisí i podpora regulárních výrazů.
• Připravte si možnost návratu zpět: exportujte aktuální konfiguraci sady pravidel přes API nebo Terraform a uložte ji.

Postupné ověřování. Podle svého oprávnění zvolte jednu z těchto možností:

1. V plánu Enterprise nasaďte spravované sady pravidel s přepsáním na úrovni sady pravidel, které nastaví akci na Log. Shromažďujte shody v Security Events po definovanou dobu pozorování, která pokrývá alespoň jeden celý obchodní cyklus.
2. V plánech Free, Pro nebo Business, kde Log není k dispozici, použijte neprodukční zónu nebo vyhrazený hostname, který přijímá reprezentativní provoz, případně omezte vynucování pomocí výrazu, který spravované sady pravidel aplikuje jen na malou část provozu, například jeden prefix cesty nebo testovací cookie. Zkontrolujte Security Events pro tuto část provozu a poté výraz postupně rozšiřujte.

Konfigurace. Změny proveďte v tomto pořadí:

1. Nasadit Cloudflare Managed Ruleset v blokovacím režimu s výjimkami zjištěnými během ověřování.
2. Nasaďte OWASP Core Ruleset na nízké úrovni paranoie a s benevolentním prahem skóre. Postupně jej zpřísňujte a po každém kroku znovu sledujte výsledky.
3. Přidejte vlastní pravidla pro cesty specifické pro danou aplikaci: administrátorská rozhraní, autentizační endpointy, obslužné nástroje pro nahrávání souborů a interní API.
4. Přidejte pravidla omezení frekvence pro endpointy autentizace, obnovení hesla, checkout a výpočetně náročné API, s prahovými hodnotami odvozenými z pozorovaného provozu, nikoli z výchozích hodnot.
5. Vymezte výjimky co nejúžeji, jak to jazyk výrazů umožňuje. Upřednostněte výjimku podle cesty, metody a ID pravidla před deaktivací pravidla pro celou zónu.

Přepnutí provozu. Vynucování povolte v období, kdy jsou vlastníci aplikace k dispozici. Měňte vždy jen jednu sadu pravidel najednou, aby bylo možné případnou regresi přiřadit ke konkrétní změně. Export předchozí konfigurace ponechte dostupný po celou dobu tohoto období.

Ověření. Před zavřením okna potvrďte následující:

• Syntetické transakce pro hlavní uživatelské scénáře proběhnou bez prověření nebo zablokování.
• Integrace zaznamenané během předpokladů stále fungují, což je ověřeno podle jejich vlastních protokolů, nikoli pouze podle analytiky Cloudflare.
• Security Events zobrazuje blokovaný provoz odpovídající očekávaným třídám útoků a žádné shlukování blokací na legitimních cestách.
• Čítače omezení frekvence požadavků se spouští na zamýšlených prahových hodnotách při běžné zátěži.

Vrácení změn. Pro vrácení změny znovu použijte exportovanou konfiguraci přes API nebo Terraform, nebo nastavte přepis na úrovni sady pravidel, který sadu pravidel deaktivuje. Před vrácením změn si zaznamenejte ID pravidel zapojených do incidentu, abyste mohli v ladění pokračovat na základě zjištěných poznatků.

Provozní hlediska

Ladění na základě důkazů. Každý blokovaný požadavek nese Ray ID; odpovídající záznam v Security Events identifikuje sadu pravidel, ID pravidla a shodné pole. Podpora by měla od uživatele vždy získat Ray ID, protože jde o jediný spolehlivý klíč zpět k danému rozhodnutí.

Vzorkování a uchovávání analytických dat se liší podle plánu. U nižších plánů se falešně pozitivní výsledek, který není včas prošetřen, už nemusí zobrazovat. Tam, kde je k dispozici Enterprise Logpush, přeposílejte firewallové události do SIEM a uchovávejte je podle vlastních zásad, místo abyste se spoléhali na uchovávání dat v dashboardu.

Obsah spravovaných pravidel se mění podle harmonogramu Cloudflare. Nová pravidla mohou začít odpovídat provozu, který dříve procházel bez zásahu. Nastavte upozorňování na objem Security Events, abyste si všimli změny v míře shody, a po jejich oznámení v Changelogu Cloudflare zkontrolujte nová spravovaná pravidla.

Pravidla omezení frekvence požadavků reagují i na sdílené adresy klientů. Provoz za carrier-grade NAT, podnikovými proxy servery nebo jedinou mobilní bránou může překročit limit na jednu IP adresu, aniž by šlo o zneužití. Pokud to plán umožňuje pomocí dalších charakteristik pro počítání, počítejte spíše podle identifikátoru relace nebo hlavičky než jen podle zdrojové adresy.

Režimy selhání, se kterými je třeba počítat: aktualizace spravovaného pravidla, která způsobí nové falešně pozitivní výsledky, výjimka širší, než bylo zamýšleno, jež tiše vypne ochranu, a origin server, který zůstává přímo dostupný, a je tak bez ohledu na konfiguraci pravidel nechráněný.

Známá úskalí

• Nasazení v režimu pouze se zaznamenáváním není dostupné mimo plán Enterprise. Postupy převzaté z dokumentace pro Enterprise se u plánů Free, Pro nebo Business nepoužijí.
• WAF chrání pouze datovou cestu Cloudflare. Pokud je IP adresa origin serveru dostupná z internetu, útočník, který ji odhalí, WAF zcela obejde. Omezte firewall na origin serveru pouze na rozsahy IP adres Cloudflare (https://www.cloudflare.com/ips/), povolte Authenticated Origin Pulls nebo připojte origin server pomocí Cloudflare Tunnel.
• OWASP Core Ruleset a Cloudflare Managed Ruleset se chovají odlišně. Zvýšení hodnoty paranoia level u OWASP bez současného snížení prahové hodnoty, nebo naopak, vede k výsledkům, které se při ladění snadno chybně interpretují.
• Vypnutí spravovaného pravidla pro celou zónu se často používá jako rychlé řešení pro jeden endpoint. Tím se ale ochrana odstraní pro veškerý provoz. Místo toho použijte výjimku omezenou na konkrétní rozsah.
• Regulární výrazy nejsou dostupné v plánech Free a Pro, proto pravidla napsaná pro zónu s plánem Business nemusí jít nasadit v zóně s plánem Pro.
• Požadavky obsloužené z cache a požadavky na hostitelské názvy typu DNS only neprocházejí stejnou cestou vyhodnocení; z jediného úspěšného testu proto neusuzujte na úplné pokrytí.
• Pokud pravidlo odkazuje na pole Attack score a skóre bota, ale oprávnění pro tato pole chybí, nevyhodnotí se podle očekávání, což může po změně plánu tiše změnit chování pravidla.

Interoperabilita

WAF sdílí ruleset engine a jazyk Rules s pravidly omezení frekvence požadavků, transformačními pravidly, přesměrovacími pravidly, cache pravidly a konfiguračními pravidly. Pravidla v různých fázích proto mohou odkazovat na stejná pole a pořadí fází určuje, které z nich se spustí jako první.

Bot Management zpřístupňuje cf.bot_management.score a související pole, na která se mohou odkazovat WAF custom rules, což je podporovaný způsob, jak kombinovat klasifikaci botů s filtrováním exploitů v jediném rozhodnutí.

Turnstile může pro relaci vystavit předběžné schválení, takže návštěvník, kterého widget již ověřil, není v proxované zóně znovu vyzýván pravidly WAF.

Workers se spouštějí až po bezpečnostních fázích v rámci zpracování požadavků Cloudflare, takže požadavek zablokovaný WAF se k Workeru vůbec nedostane. Pokud se zdá, že Worker a pravidlo WAF jsou v konfliktu, podívejte se na zdokumentované pořadí zpracování provozu.

API Shield přidává ověřování schémat, vynucování klientských certifikátů mTLS a zjišťování endpointů pro provoz API a lze jej kombinovat s pravidly WAF na stejných hostname.

Časté dotazy

Kontroluje WAF těla požadavků? Ano, až do zdokumentované maximální kontrolované velikosti, přičemž dostupná pole pro kontrolu těla závisí na plánu a typu obsahu. Obsah nad rámec kontrolované velikosti se přeposílá bez vyhodnocení na základě těla.

Platí pravidla WAF i pro provoz API? Ano. Pravidla se vyhodnocují u každého proxovaného požadavku HTTP, včetně JSON API a koncových bodů pro komunikaci mezi zařízeními. Upozorňujeme, že akce s výzvou nemůže vyřešit klient, který není prohlížeč, proto by se pro cesty API měla místo výzvy používat akce Block nebo omezení frekvence požadavků.

Jak se dohledává falešně pozitivní výsledek? Zaznamenejte Ray ID z ovlivněné odpovědi, vyhledejte událost v Security Events a z položky vyčtěte ID sady pravidel a ID pravidla. Výjimku omezte na toto ID pravidla, cestu a metodu.

Zdroje

• https://developers.cloudflare.com/waf/, staženo 2026-08-28.
• https://developers.cloudflare.com/waf/custom-rules/, staženo 2026-08-28.
• https://developers.cloudflare.com/waf/rate-limiting-rules/, staženo 2026-08-28.
• https://developers.cloudflare.com/waf/managed-rules/, staženo 2026-08-28.
• https://developers.cloudflare.com/waf/detections/, staženo 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/rules-language/actions/, staženo 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/reference/phases-list/, staženo 2026-08-28.
• https://www.cloudflare.com/network/, staženo 2026-08-28.
• https://www.cloudflare.com/ips/, staženo 2026-08-28.

Snímek obsahu: 2026-08-28.

Changelog