← Všechny produkty

Web Application Firewall (WAF)

Cloudflare WAF vyhodnocuje HTTP požadavky procházející přes proxy podle vlastních pravidel, pravidel omezení frekvence požadavků a spravovaných sad 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í. Opravy zranitelností doplňuje, nenahrazuje: v době mezi zveřejněním zranitelnosti a nasazením opravy snižuje expozici vůči známým třídám zneužití a automatizovanému skenování.

Cloudflare WAF běží v datových centrech Cloudflare, která proxují provoz dané zóny. Cloudflare uvádí, že jeho síť funguje ve 348 městech (https://www.cloudflare.com/network/, staženo 2026-08-28). Kontroluje se pouze provoz, který je proxovaný přes Cloudflare. Mimo WAF zůstává záznam typu DNS only, hostname přeložený mimo zónu i 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í spravovaných pravidel, proto frekvenci aktualizací popisujeme jako proces řízený dodavatelem, ne jako závazek k době reakce.

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

Architektura

TLS požadavku na hostname za proxy Cloudflare se ukončuje v datovém centru Cloudflare, které vybere anycastové směrování. 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í. Ukončující akce zastaví vyhodnocování zbývajících pravidel pro daný požadavek, neukončující akce nechá vyhodnocování pokračovat. Úplný seznam fází včetně transform, redirect a cache uvádí reference fází (viz Zdroje).

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í: na pole musí odkázat pravidlo a určit akci. Zapnutí detekce proto provoz nezmění, 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: porovnává požadavek s obecnými vzory útoků, sčítá skóre a zasáhne, jakmile skóre překročí nastavenou prahovou hodnotu při zvolené ú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řepisů: přepis na úrovni sady pravidel mění akci nebo stav celé sady, přepis podle štítků mění skupinu pravidel a přepis 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. Pokud pravidla spravujete jako kód, ukládejte do verzovacího systému i pořadí pravidel a pořadí nasazení sad pravidel, protože jsou součástí konfigurace.

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.

Plán Pro má stejné charakteristiky počítání jako Free. Pravidlo rate limitingu, které počítá podle čehokoli jiného než zdrojové adresy, vyžaduje plán Business nebo Enterprise. To je častý důvod, proč pravidlo navržené v jednom plánu nejde 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.
• WAF kontroluje tělo požadavku jen do maximální kontrolované velikosti; 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 nedělají. Zapnutí 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.
• Ověřte, na jakém plánu zóna je, protože na něm závisí dostupnost akce Log i podpora regulárních výrazů.
• Připravte si cestu 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. Nasaďte 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. Výjimky vymezte tak úzce, jak to jazyk výrazů dovolí. 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é v předpokladech stále fungují, a to podle jejich vlastních logů, ne jen 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. Znovu nasaďte exportovanou konfiguraci přes API nebo Terraform, nebo nastavte přepis na úrovni sady pravidel, který sadu deaktivuje. Předtím si zaznamenejte ID pravidel zapojených do incidentu, abyste mohli v ladění pokračovat.

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 jen podle něj lze konkrétní rozhodnutí spolehlivě dohledat.

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 vydat pre-clearance, takže návštěvník, kterého widget už ověřil, nedostane v proxované zóně další výzvu od pravidel 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. Výzvu ale klient, který není prohlížeč, nevyřeší, proto pro cesty API používejte místo výzvy akci 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