Cloudflare WAF WordPress instellen: een nuchter stappenplan

Cloudflare WAF WordPress instellen is een van die taken waar mensen of te enthousiast aan beginnen (en hun eigen site uitsluiten) of het uitstellen omdat het ingewikkeld lijkt. In de praktijk valt het mee: drie managed-ruleset-knoppen en vier custom rules dekken 80% van de aanvallen die ik dagelijks in logs voorbij zie komen. Een gehackte site is vervelend, geen ramp, maar als Cloudflare ervoor staat, zien de meeste botnets je site niet eens.

Dit artikel is geschreven voor WordPress, maar het meeste werkt identiek op Laravel, Statamic of een statische headless setup. Aan het einde benoem ik per stack waar het verschilt.

Verbeteren boven herbouwen: Cloudflare zet je voor je site, je hoeft niets aan je hosting te veranderen.

Wat een WAF wel en niet doet (en waarom edge beter is dan plugin)

Een Web Application Firewall (WAF) filtert HTTP-requests op basis van regels: bekende attack-patronen, verdachte payloads, geo-locatie, IP-reputatie. Wat er overblijft, bereikt je site. Wat geblokkeerd wordt, krijgt een 403 of een challenge.

Het verschil tussen een edge-WAF (Cloudflare, Sucuri, AWS WAF) en een plugin-WAF (Wordfence, iThemes Security) zit in het moment waarop het filter werkt:

• Edge: Cloudflare ziet de request voordat hij ooit bij je origin-server komt. Geblokkeerde requests kosten je server geen CPU, geen database-queries, geen PHP-time.
• Plugin: Wordfence ziet de request pas nadat WordPress is gestart, PHP heeft geladen en de plugin is geinitialiseerd. Een SQL-injection-poging heeft op dat moment al een database-verbinding tot gevolg gehad.

Allebei hebben ze nut. In mijn ervaring is de combinatie het sterkste: Cloudflare voor de eerste laag (de massa botnet-ruis), Wordfence voor de detectie op origin-niveau (gerichtere aanvallen, malware-scan).

Cloudflare WAF WordPress instellen begint bij DNS en proxy

Zonder de proxy is er geen WAF. De eerste stap is dus altijd DNS:

1. Maak een gratis Cloudflare-account aan en voeg je domein toe.
2. Cloudflare scant je huidige DNS-records en stelt ze voor.
3. Wijzig de nameservers bij je registrar (TransIP, Argeweb, Mijn Domein) naar de Cloudflare-nameservers.
4. Wacht tot Cloudflare actief is (vaak binnen het uur, soms tot 24 uur).
5. Zet voor je hoofd-A-record en www-CNAME het oranje wolkje aan (Proxied).

SSL-mode op Full (strict). Cloudflare biedt vier SSL-modi: Off, Flexible, Full, Full (strict). Kies altijd Full (strict). Flexible breekt elke WordPress-site met mixed-content of canonical-loops, en het is in 2026 geen serieuze optie meer. Full (strict) vereist een geldig certificaat op je origin. Heb je Let’s Encrypt of een hosting-certificaat draaien: prima.

Always Use HTTPS: aan. Stuurt elke HTTP-request automatisch door naar HTTPS. HSTS pas aanzetten nadat je 100% zeker weet dat de redirect klopt: HSTS is een eenrichtingsweg.

Managed Rules: wat krijg je op Free, Pro en Business

Cloudflare’s gratis plan biedt al meer dan veel betaalde concurrenten:

• Basis managed ruleset (algemene OWASP-achtige bescherming)
• 5 custom rules
• DDoS-bescherming op laag 3/4
• Bot Fight Mode

Wat je mist op Free is de WordPress-specifieke managed ruleset. Die zit vanaf Pro (USD 25 per maand per domein). In mijn ervaring is dat de moeite waard vanaf ongeveer 1000 dagelijkse bezoekers, of bij webshops waar elk uur downtime geld kost.

Pro voegt toe:

• WordPress managed ruleset (specifieke regels voor wp-login, wp-admin, xmlrpc, REST API)
• OWASP Core Ruleset
• Super Bot Fight Mode (slimmere bot-detectie)

Business voegt toe:

• Custom-rules op headers en bodies (handig voor specifieke payload-detectie)
• 100% uptime SLA
• Cloudflare biedt zelf 24/7-supportkanalen (Lypii heeft geen 24/7-support)

Aan de slag op Free is prima om te beginnen. Schaal je op of merk je dat de managed ruleset op Pro daadwerkelijke aanvallen tegenhoudt, dan rechtvaardigt het zichzelf snel.

Custom Rules die ik standaard aanzet voor WordPress

In het Cloudflare-dashboard ga je naar Security > WAF > Custom rules. Vier regels die ik op vrijwel elke klant-site aanzet:

Rate limit op wp-login.php

Expressie:

(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")

Action: Rate Limit, 5 requests per 1 minuut per IP. Voorkomt brute force zonder een plugin op origin-niveau nodig te hebben.

XML-RPC blokkeren

Expressie:

(http.request.uri.path eq "/xmlrpc.php")

Action: Block. XML-RPC is een oude API die nog steeds aangeroepen wordt voor brute force en pingback-aanvallen. Tenzij je Jetpack of de WordPress-mobiel-app gebruikt, hoort dit endpoint dicht.

Admin geo-fence

Expressie:

(http.request.uri.path contains "/wp-admin" and ip.geoip.country ne "NL" and ip.geoip.country ne "BE")

Action: Managed Challenge. Werk je vanuit Nederland en Belgie? Dan krijgt elke admin-request uit een ander land een captcha. Reis je af en toe? Whitelist tijdelijk je IP.

REST API beperken

Expressie:

(http.request.uri.path contains "/wp-json/wp/v2/users" and not ip.src in {<jouw IP>})

Action: Block. De REST API lekt standaard gebruikersnamen via /wp-json/wp/v2/users. Niet kritiek, wel ruis-reductie voor brute force op username-vector.

Voor IP-geolocatie geldt: Cloudflare loggt die op IP-niveau. Heb je een privacy-policy waarin je deze logging niet hebt opgenomen, dan is dat een AVG-punt om mee te nemen. Bij specifieke vragen daarover: een privacy-advocaat geeft hier juridisch advies. Lypii doet dat niet.

Rate limiting: hoe voorkom je dat je Googlebot uitsluit

Rate limiting is krachtig en gevaarlijk tegelijk. Verkeerd ingesteld sluit het Googlebot uit, en dan kelderen je rankings binnen weken.

Twee veiligheidsmaatregelen:

1. Start in “Log”-modus. Cloudflare laat je een rule eerst alleen loggen voordat hij blokkeert. Doe dat minimaal 7 dagen. Bekijk in Security Events welke requests geraakt worden. Zit Googlebot ertussen, je eigen IP, een legitieme uptime-monitor? Pas dan de regel aan voordat je hem op Block zet.
2. Throttle in plaats van Block. Voor onbekende grijze-gebied-requests is “Managed Challenge” of “JS Challenge” milder dan “Block”. De echte browsers passeren, de echte bots niet.

Googlebot zelf herken je aan zijn user-agent en aan IP-ranges die Google publiceert. Een whitelist op (cf.client.bot) (Cloudflare’s eigen bot-detectie) helpt: Cloudflare verifieert daar de bekende good-bots zoals Googlebot en Bingbot.

Page Rules en cache: WAF werkt samen met caching

De WAF en de cache van Cloudflare zijn aparte producten, maar je stelt ze in dezelfde dashboard in en ze beinvloeden elkaar.

Page Rule voor /wp-admin:

• Cache Level: Bypass
• Security Level: High
• Disable Performance

Je wilt dat /wp-admin nooit gecached wordt (admins krijgen anders een pagina van vijf minuten oud te zien), en je wilt er meer security op (vaker captcha).

Cache Everything voor de front-end:

• Pas aanzetten nadat je hardening klaar is
• Niet voor dynamische URL’s (/cart, /checkout, /my-account)
• Edge TTL: 2 uur is een goede start

Op WooCommerce hoort de cache nooit op cookie-loze sessies te draaien zonder uitzonderingen. Een verkeerde cache-config laat klant A de cart van klant B zien. Dat is een veel groter incident dan een hack.

Logs lezen en false positives oplossen

Onder Security > Events zie je elke blok-actie. Filter op de laatste 24 uur of de laatste week, sorteer op IP of op rule. Patronen die je zoekt:

• IP’s die honderden requests doen op /wp-login.php (botnet-brute-force, je rate-limit doet z’n werk)
• Eigen kantoor-IP dat te vaak een challenge krijgt (whitelist via IP Access Rules)
• Plugins of services die unexpected geblokkeerd worden (Mailchimp’s webhooks, Google Search Console verificatie)

Een false positive op je eigen werk los je op via twee routes: een Exception in de Managed Rules, of een Skip-rule in Custom Rules. Begin met de minst brede uitzondering.

Multi-stack: hetzelfde werkt op Laravel, Statamic, headless

Cloudflare WAF werkt op elke origin: WordPress, Laravel, Statamic, Next.js, een statische site op Netlify. De principes zijn identiek, alleen de paden verschillen.

• Laravel: rate limit op /login in plaats van /wp-login.php. Vervang xmlrpc.php met blocks op endpoints die je niet exposed wilt.
• Statamic: vergelijkbaar, plus rate limit op /!/auth voor de control panel.
• Headless WordPress: admin (origin) blijft volledig achter de WAF, front-end gaat over CDN. Beste-van-twee-werelden, mits je de juiste paden whitelisted voor je build-pipeline.

De WordPress-specifieke managed ruleset blijft uniek voor WP. Voor de andere stacks combineer je OWASP Core + eigen custom rules.

Wat ik altijd doe na een Cloudflare-installatie

Een korte checklist die ik op elke klant-site afloop:

1. DNS-records nagaan, oranje wolkje aan waar het moet
2. SSL op Full (strict), Always Use HTTPS aan
3. Managed Rules aan, op Log-modus voor de eerste week
4. Custom rules voor wp-login, xmlrpc, admin geo-fence, REST API
5. Page Rules voor /wp-admin en /wp-login.php
6. Bot Fight Mode aan (Pro+: Super Bot Fight Mode)
7. Whitelist mijn eigen kantoor-IP en bekende bots
8. Een week later: Security Events bekijken, regels op Block zetten

Voor de officiele documentatie en de meest recente expressie-syntax raad ik Cloudflare’s WAF-developer-docs aan. Engels en uitgebreid.

Twijfel je of jouw stack samenwerkt met Cloudflare-proxying? Direct contact en ik check het binnen 24 uur. Meer over website onderhoud en wat ik standaard meeneem in een security-pakket.