Web application firewall WordPress MKB kiezen: gids 2026

Een klant met een webshop in Hulst belde me eind mei. Haar server-logs toonden ruim 500 login-pogingen per dag op /wp-login.php, vanaf willekeurige IP-adressen in Rusland, Vietnam en Brazilië. Klassieke situatie voor iedere Nederlandse ondernemer die zelf een web application firewall wordpress mkb kiezen wil.

Ze had eerder al Wordfence Free draaien, twijfelde over Cloudflare Pro, en las tegelijk over Sucuri en Ninja Firewall. Zulke vergelijkingen heb ik zelf al meer dan twintig keer gedaan, voor klanten in Zeeuws-Vlaanderen en West-Vlaanderen. Er zit patroon in wie welke tool nodig heeft.

In dit stuk lees je hoe de drie WAF-lagen werken, welke tool bij welk verkeersprofiel past en welke combinaties conflicteren. Geen whitepapers, geen Reddit-threads. Reken op 20 minuten lezen, en je weet wat je nodig hebt.

Wat een WAF doet, en op welke laag hij zit

Een web application firewall filtert HTTP-requests op kwaadaardige patronen. Denk aan SQL-injectie, cross-site scripting, path-traversal, credential stuffing, brute-force login-pogingen en scans naar bekende plugin-kwetsbaarheden. Waar hij dat doet is bepalend voor performance, false-positives en welke tool je überhaupt kan gebruiken.

Er zijn drie plekken waar een WAF kan draaien:

1. Cloud- of DNS-niveau. Je verkeer wordt door DNS-wijziging (nameservers of A-record) via een proxy geleid. Cloudflare en Sucuri Firewall werken zo. De request bereikt je server pas nadat de proxy hem heeft gefilterd. Voordeel: DDoS wordt opgevangen vóór je hosting. Nadeel: als de proxy uitvalt, is je site onbereikbaar.
2. Endpoint- of plugin-niveau. Een WordPress-plugin die de PHP-request evalueert nadat hij op de server is aangekomen. Wordfence, Ninja Firewall en Solid Security werken zo. Voordeel: kent context van je site (welke gebruiker, welk endpoint) en kan malware scannen. Nadeel: je server draagt al de last van botverkeer.
3. Server- of ruleset-niveau. ModSecurity met de OWASP Core Rule Set (CRS), of Imunify360, ingebakken in cPanel of DirectAdmin. Draait onder Apache/LiteSpeed of Nginx. Voordeel: onafhankelijk van WordPress, blokkeert vóór PHP laadt. Nadeel: veel false-positives op WordPress admin-POSTs bij hoge paranoia-niveaus, volgens de OWASP CRS-documentatie zelf een reëel probleem.

De drie lagen hebben ieder duidelijke voordelen en nadelen. In de volgende tabel zet ik ze naast elkaar.

Voor het MKB draait de keuze in 90% van de gevallen tussen laag 1 (Cloudflare) en laag 2 (Wordfence of Ninja). Server-laag komt in beeld bij VPS-hosting of hoster-inclusief. Dat verklaart waarom de vergelijking hierna vooral op laag 1 en 2 focust.

Feature-matrix: alle populaire WAF-opties naast elkaar

De volgende matrix vergelijkt de meest voorkomende tools op de features die ik in klant-audits controleer. Prijzen zijn geverifieerd via de leveranciersites in augustus 2026.

Prijzen te verifiëren via Cloudflare Plans, Wordfence Pricing en de Sucuri prijspagina.

De belangrijkste conclusies uit deze matrix zijn:

1. Cloudflare Free biedt DNS-proxy en CDN voor €0, maar geen malware-scan.
2. Wordfence Free scant wel, maar zonder real-time signatures (30 dagen vertraging).
3. Sucuri is de enige tool met cleanup-garantie in het basispakket.
4. Ninja Firewall Pro is de goedkoopste betaalde optie met echte rate-limiting, maar mist 2FA en malware-scan.

Web application firewall WordPress MKB kiezen: beslisboom per situatie

Er is geen universeel goede keuze. Wel is er per bezoekersprofiel een combinatie die in mijn praktijk 8 op de 10 keer de juiste blijkt. Onderstaande roadmap is de beslisboom die ik zelf gebruik bij een klant-intake:

1. Traffic onder 5.000 bezoekers/maand, budget €0. Cloudflare Free + Wordfence Free. Cloudflare doet DNS-proxy, verbergt je origin-IP en absorbeert basale DDoS. Wordfence Free voegt login-lockdown en 2FA toe. Nadeel: malware-signatures 30 dagen vertraagd. Voor een corporate site of blog zonder e-commerce is dat acceptabel.
2. Traffic 5.000–50.000 en actieve brute-force problemen. Cloudflare Pro ($25/mnd) + Wordfence Premium ($149/jr). Zet in Cloudflare een rate-limit rule op /wp-login.php (max 5 per minuut per IP) en Wordfence’s login-throttle op 3 fouten voor lockout. Deze combi elimineert 95% van brute-force zonder gebruikers te hinderen.
3. E-commerce met Mollie, Stripe of Adyen. Cloudflare Pro + Wordfence Premium, met expliciete allowlist voor webhook-IP’s. Bij WooCommerce is een fout in de webhook-flow duurder dan de false-positive zelf: één gemiste iDEAL-callback en de order blijft op “pending” hangen. IP-ranges voor Mollie staan gedocumenteerd op de Mollie-developerspagina.
4. Financieel, juridisch of gezondheid (high-risk target). Sucuri Pro ($299,99/jr) met onbeperkte cleanup. Voor een YMYL-site die persoonsgegevens verwerkt is een cleanup-SLA meer waard dan een goedkopere plugin. Meldplicht datalek bij de Autoriteit Persoonsgegevens begint bij 72 uur, dus wachten op een externe cleaner is geen optie.
5. Managed hosting (Kinsta, WP Engine, Cloudways, Savvii). Kinsta bundelt Cloudflare Enterprise-WAF in elke plan vanaf $35/mnd, WP Engine heeft ingebouwde WAF via hun global edge network. In die gevallen extra: Wordfence Free voor 2FA en malware-scan, geen tweede DNS-laag toevoegen (dubbele proxy = brekende redirects).
6. Freelance-webmaster of agency met 10+ klant-sites. Wordfence heeft een Multisite Care/Response, maar de betere prijs zit in Patchstack of MalCare’s site-management dashboard. Ninja Firewall’s centralized-logging is dan meer waard dan de individuele feature-parity.

Deze zes situaties dekken 90% van wat ik in Zeeland en Vlaanderen tegenkom. Voor de 10% niches (headless WordPress, multi-region CDN, PCI DSS Level 1 scope) is de matrix niet toereikend en heb je een audit nodig.

Overlap: welke feature van welke tool?

Wanneer je Cloudflare en Wordfence naast elkaar draait, doen ze een deel van hetzelfde werk. Welke van de twee neemt welke feature? De volgende tabel is het uitgangspunt dat ik in klant-installaties hanteer:

Vuistregel: wat Cloudflare op de edge kan filteren, laat je door Cloudflare doen (bespaart PHP-resources). Wat context nodig heeft ("wie is deze user? welk endpoint?") laat je door Wordfence doen. De overlap in WAF-rules is meestal ok, mits je de logs van beide monitort en dubbele blocks (allowlist in Cloudflare, block in Wordfence) oplost.

Setup per hostingpaneel

De praktische kant. Wat kost het om een WAF live te krijgen op de meest voorkomende Nederlandse en Belgische hostingpanelen?

Cloudflare DNS-routering activeren

1. Maak een gratis account op cloudflare.com en voeg je domein toe.
2. Cloudflare scant je bestaande DNS-records en toont ze in een preview.
3. Kopieer de twee nameservers die Cloudflare toewijst (bijvoorbeeld chloe.ns.cloudflare.com en oliver.ns.cloudflare.com).
4. Wijzig nameservers in je registrar:

• TransIP: Domeinen → jouwsite.nl → Nameservers → "Andere nameservers gebruiken" → beide invoeren.
• Antagonist: Klantenservice → Domeinen → nameservers wijzigen → beide invoeren.
• Combell: Configuratie → Domeinnaam → DNS-instellingen → nameservers overschrijven.

1. Wacht 15 minuten tot 24 uur op DNS-propagatie. Cloudflare stuurt een e-mail zodra de switch actief is.

Cloudflare Transform Rule voor XML-RPC-block

XML-RPC is een klassiek brute-force en pingback-doel. Blokkeer het via een custom rule in Cloudflare:

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

Voeg toe onder Security → WAF → Custom Rules → Create rule → paste bovenstaande expression → Action: Block. Werkt op elk plan, ook Free.

Wordfence installatie via WP-CLI

Voor SSH-gebruikers is de snelste installatie:

# Wordfence installeren en activeren
wp plugin install wordfence --activate

# Activatie-timestamp registreren
wp option update wordfence_activation_time $(date +%s)

# API-key koppelen (interactief, uit e-mail)
wp option update wordfence_api_key JOUW_KEY_HIER

Daarna in wp-admin: Wordfence → Firewall → Optimize the Firewall → volg de learning-mode-wizard van 7 dagen. Wordfence leest je server-config (Apache/Nginx/LiteSpeed) en installeert een .user.ini waardoor de firewall vóór WordPress laadt.

Voor extra login-bescherming in wp-config.php:

// Wordfence Login Security captcha op v3 zetten
define('WORDFENCE_LS_CAPTCHA', 'v3');

Sucuri Firewall API-keys setup

1. Log in op je Sucuri-dashboard, ga naar Website Firewall → Settings → API.
2. Kopieer de "API key" en "Secret" (beide 32-tekens hex).
3. Installeer de gratis Sucuri Security-plugin uit de WP-repository.
4. Ga naar Sucuri Security → Firewall → API Key → plak beide in.
5. Wijzig in je DNS: A-record voor je root en www naar het IP dat Sucuri opgeeft (varieert per klant, staat in Firewall → General Settings).

DirectAdmin ModSecurity aanzetten

Voor Neostrada en Argeweb (DirectAdmin-basis):

1. Log in op DirectAdmin → Account Manager → ModSecurity.
2. Toggle "Enable ModSecurity" naar Aan.
3. Selecteer ruleset "OWASP CRS" (voorkeur boven Comodo, minder false-positives op WooCommerce).
4. Zet Paranoia Level op 1 (niet 2 of 3, dat blokkeert legitieme WP-admin POSTs).
5. Whitelist rule 218500 en 942100 (bekende WooCommerce/WordPress false-positives).

Bij twijfel: eerst 48 uur in "detection mode" draaien, ModSecurity-log lezen via DirectAdmin → Advanced Features → Access & Error Logs, dan pas naar "blocking mode".

cPanel WHM ModSecurity

Voor Antagonist, Vimexx en Hostnet (cPanel-basis, WHM-toegang bij VPS):

1. Log in op WHM → Security Center → ModSecurity Vendors.
2. Installeer "OWASP ModSecurity Core Rule Set" als vendor.
3. Ga naar ModSecurity Configuration → SecRuleEngine → zet op "DetectionOnly" voor 48 uur.
4. Log naar /etc/apache2/logs/modsec_audit.log schrijft nu welke rules zouden triggeren.
5. Whitelist per site via WHM → ModSecurity Tools → Hits List → "Disable Rule for this site".
6. Zet daarna SecRuleEngine op "On".

Zonder WHM-toegang (shared cPanel-hosting) is ModSecurity meestal al aan of vergrendeld. Vraag support om per-site false-positives te whitelisten.

Drie concrete scenario's uit klantpraktijk

Scenario A: Cloudflare Pro te aggressive voor Belgische bezoekers

Klant in Kaprijke merkte dat Vlaamse bezoekers challenge-pages kregen op checkout. Nederlandse bezoekers stroomden wel gewoon door. Zo'n challenge-page is een JavaScript-check. Cloudflare's "Bot Fight Mode" bleek te agressief op Belgacom-IP-blocks.

Fix: Cloudflare dashboard → Security → Bots → Bot Fight Mode → Off. Vervangen door custom rule:

(cf.threat_score gt 30 and http.request.uri.path contains "/wp-login")
Action: Managed Challenge

Alleen challenge bij verdachte score EN login-URL. Vlaamse checkout-flow onaangetast.

Scenario B: Wordfence blokkeert Mollie-webhook

Een klant in Sint-Niklaas kreeg iDEAL-orders die "pending" bleven omdat Wordfence de Mollie-webhook-POST als "suspicious pattern" blokkeerde. Live Traffic-log toonde 403 Blocked by firewall rule 39.

Fix: Wordfence → Firewall → All Firewall Options → Whitelisted URLs → toevoegen /wc-api/mollie_return en /wc-api/mollie_wc_gateway_ideal_webhook. Daarnaast Mollie's IP-range whitelisten via Wordfence → Blocking → IP Access Rules → Allow: 104.211.238.0/24. Webhook binnen 10 minuten weer werkend, geen verloren orders.

Scenario C: Sucuri cleanup na hack

Klant in Middelburg belde op zaterdagavond: site redirected bezoekers via Google-zoekresultaten naar een Turkse gok-affiliate. Wordfence Free had de infectie 3 dagen eerder al gedetecteerd maar mail-notificaties gingen naar een oude adres.

Wat gebeurde:

1. Zaterdag 22:00: contact opgenomen met Sucuri via Emergency Cleanup ($199).
2. Zondag 04:00 (6 uur later): eerste diagnose. Twee backdoors in wp-content/uploads/2023/ en één in mu-plugins/.
3. Zondag 14:00: cleanup afgerond, wachtwoorden gereset, secret keys in wp-config.php opnieuw gegenereerd.
4. Maandag: klant overgestapt naar Sucuri Pro-jaarabonnement ($299,99) voor onbeperkte cleanups.

Kosten: €175 emergency + €280 abonnement + 2u van mij voor DNS-migratie en post-mortem = €600 totaal. Zonder Sucuri had de klant richting €1.500 gezeten en 2 dagen downtime.

WAF-stapelen: overlap, conflict en volgorde

Meerdere WAF-lagen tegelijk kán werken, maar loopt vaak stuk op IP-propagatie. Wat je moet weten:

1. Cloudflare proxied verkeer → jouw server ziet Cloudflare-IP, niet echte bezoeker. Installeer de Cloudflare-plugin voor WordPress of voeg de volgende snippet toe aan wp-config.php.

// Echte bezoeker-IP uit Cloudflare-header halen
if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

Zonder deze snippet blokkeert Wordfence Cloudflare-IP's in plaats van aanvallers.

1. Log-diagnostics om te zien wie blocked. Bij een klacht "ik kom niet op de site" loop je dit af.

• Check Cloudflare dashboard → Security → Events → filter op bezoeker-IP.
• Als geen event: check Wordfence → Tools → Live Traffic → filter op IP.
• Als geen event: check server error-log (cPanel: Metrics → Errors; DirectAdmin: Access & Error Logs) voor ModSecurity-hits.

1. IP-allowlist volgorde: Cloudflare → server → WordPress. Wanneer je een IP wilt whitelisten, doe het in alle lagen. Anders blokkeert de tweede laag alsnog. Volgorde in mijn workflow.

• Cloudflare Firewall Rules → Allow IP.
• Server-level (.htaccess of firewall van hoster) → Allow IP.
• Wordfence Blocking → IP Access Rules → Allow.

1. Wanneer overlap OK is: Cloudflare voor DDoS + Wordfence voor endpoint-context. Cloudflare doet globale rate-limits, Wordfence de fijnmazige rules.
2. Wanneer conflict optreedt: Cloudflare Pro's Managed Ruleset + Wordfence Firewall op Extended Protection kunnen dezelfde SQLi-poging dubbel loggen. Niet gevaarlijk, wel verwarrend. Los op door één van beide te configureren op "Log only" en de ander op "Block".

Wanneer je géén WAF nodig hebt

Niet elke site verdient de configuratie-overhead. Situaties waar ik géén WAF adviseer:

1. Low-traffic personal blog zonder logins. Als je site geen wp-admin openbaar toont (via .htaccess IP-restrict) en geen forms heeft, is de aanvalsvector minimaal. Regelmatige backups + core-updates zijn genoeg.
2. Landingspagina zonder formulieren. Een statische campagnepagina op WordPress is functioneel een brochure. Cloudflare Free voor DDoS is nog verstandig, verder niets.
3. Kortlevende marketing-site (onder 3 maanden). De setup-tijd van Wordfence learning-mode is 7 dagen. Voor een 8-weekse campagne loont dat niet. Cloudflare Free volstaat.
4. Site achter een managed edge (Kinsta, WP Engine). Zoals eerder: dubbele proxy geeft brekende redirects. Enkel Wordfence Free voor 2FA volstaat.

Wanneer een webmaster inschakelen

Doe de setup zelf als je binnen 90 minuten via bovenstaande stappen bij een werkende configuratie bent. Bel iemand in als:

1. Je een gehackte site hebt met omzet-impact (elke minuut redirect kost bezoekers).
2. Je Cloudflare Business of Enterprise moet configureren met de Bot Management add-on (custom prijs op offerte-basis, doorgaans enterprise-tier).
3. Je meer dan 5 klant-sites tegelijk beheert en centralized-logging nodig hebt.
4. Je een PCI DSS-scope hebt en de WAF-configuratie moet documenteren voor auditors.

Voor mijn klanten kost een volledige WAF-setup (Cloudflare + Wordfence + config) 2 tot 3 uur werk (€140 tot €210), inclusief 7-daagse follow-up voor false-positive tuning.

Vast in de keuze?

Kom je er niet uit welke WAF-combinatie bij jouw MKB-site past, of loopt je huidige setup vast op false-positives? Stuur me een mail via /contact/. Ik doe een 30 minuten audit op basis van je site-URL en actuele config, en geef een concreet advies met setup-tijd en kosten. Factuur alleen daadwerkelijk bestede uren aan €70, zonder minimumafname.