--- title: "WAF: wat een web application firewall is en doet" description: "Een WAF (web application firewall) controleert het verkeer naar een website en blokkeert aanvallen zoals SQL-injectie en XSS." canonical: https://www.keurigonline.nl/begrippenlijst/waf last_modified: 2025-12-18 --- [Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst) # WAF Een WAF (web application firewall) controleert het verkeer naar een website en blokkeert aanvallen zoals SQL-injectie en XSS. Actueel: [CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive) Een WAF, voluit web application firewall, is een firewall die het webverkeer naar een website inhoudelijk controleert en verdachte verzoeken tegenhoudt voordat ze de applicatie bereiken. Een gewone netwerkfirewall kijkt vooral naar IP-adressen en poorten. Een WAF leest juist wat er in een HTTP-verzoek staat, zoals de URL, de formuliervelden en de headers. De WAF vergelijkt elk verzoek met een set regels. Een veelgebruikte, open regelset is de OWASP Core Rule Set voor de WAF-engine ModSecurity, met regels tegen onder meer SQL-injectie en cross-site scripting (XSS). Raakt een verzoek een regel, dan krijgt de bezoeker meestal de foutcode 403 Forbidden te zien in plaats van de pagina. Een WAF is een extra laag en geen vervanging voor updates, want wie een fout begrijpt, kan een handtekening vaak omzeilen. Regels kunnen ook een gewoon verzoek blokkeren, een vals alarm dat false positive heet. Het grote voordeel is snelheid: bij een nieuw lek rolt een leverancier soms binnen enkele uren een regel uit, lang voordat elke website is bijgewerkt. Op het grootste deel van de shared hosting van KeurigOnline werkt Imunify360 als WAF. Tijdens het PHP-lek van 21 oktober 2026 kreeg die dezelfde ochtend een regel tegen het aanvalspatroon, en 's avonds nieuwe regels tegen de publieke aanvalstool. Krijg je bij het opslaan van een formulier onverwacht een 403-fout, dan kan een WAF-regel de oorzaak zijn. Geef bij je vraag dan de URL en het exacte tijdstip door, zodat de blokkade in de logs terug te vinden is. ## Geschiedenis De eerste WAF's kwamen eind jaren negentig op de markt, toen aanvallen op webservers toenamen ([Wikipedia](https://en.wikipedia.org/wiki/Web_application_firewall)). In november 2002 bracht Ivan Ristić ModSecurity uit, een open-source WAF die begon als module voor Apache ([Wikipedia](https://en.wikipedia.org/wiki/ModSecurity)). Belangrijke mijlpalen: - **Eind jaren 90:** Eerste commerciële WAF's, onder meer van Kavado en Gilian - **November 2002:** Eerste versie van ModSecurity - **Oktober 2008:** Een toelichting bij PCI DSS-eis 6.6 legt vast wat een WAF is, voor organisaties die betaalkaartgegevens verwerken - **Februari 2024:** Trustwave draagt ModSecurity over aan [OWASP](https://owasp.org/www-project-modsecurity/), dat ook de [Core Rule Set](https://coreruleset.org/) onderhoudt ## Bronnen 1. **OWASP** - [Web Application Firewall](https://community.owasp.org/Web_Application_Firewall) 2. **OWASP CRS** - [OWASP CRS: generic attack detection rules for ModSecurity](https://coreruleset.org/) 3. **OWASP** - [OWASP ModSecurity](https://owasp.org/www-project-modsecurity/) 4. **F5** - [What is a Web Application Firewall (WAF)?](https://www.f5.com/glossary/web-application-firewall-waf) 5. **Wikipedia** - [Web application firewall](https://en.wikipedia.org/wiki/Web_application_firewall) ## Gerelateerde artikelen Beveiliging 22 okt 2026 [CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive) Onder Apache met mod\_lsapi ververst lsphp zich na een graceful vanzelf. Alleen idle processen, zoals die van webmail, moesten we daar met de hand stoppen. ## Laag 2: Imunify360 als WAF CloudLinux zag al op 21 oktober pogingen die op het rondgaande aanvalspatroon leken, en zette er een ModSecurity-regel tegen in de Imunify360-ruleset\[3\]. Ruleset 8.85 voegde daar regels aan toe voor de publieke aanvalstool, varianten daarvan en verdachte uploads. Op servers waar Imunify360 nog ontbrak, hebben we het die ochtend geïnstalleerd (agent 8.14.1). Daarna hebben we per server gecontroleerd welke ruleset geladen was, en lokaal getest dat een normaal request 200 gaf en een request met het exploitkenmerk 403 (blokregel 77318849). Beveiliging 21 jul 2026 [WordPress CVE-2026-63030 beveiligen: patch nu (wp2shell)](https://www.keurigonline.nl/blog/wordpress-cve-2026-63030-beveiligen) Wil je dit soort noodpatches in het vervolg niet meer handmatig hoeven volgen? Lees ook ons artikel over [structureel updatebeleid voor WordPress](https://www.keurigonline.nl/blog/wordpress-plugins-updaten-tegen-kwetsbaarheden), zodat je bij de volgende kwetsbaarheid niet weer achter de feiten aanloopt. ## Kun je niet meteen updaten? Tijdelijke noodmaatregel Draai je een maatwerkomgeving waarin updaten niet meteen kan, bijvoorbeeld door custom code die eerst getest moet worden? Blokkeer dan tijdelijk toegang tot het kwetsbare endpoint op je firewall of edge-niveau (WAF, Cloudflare, of vergelijkbaar). **Let op: blokkeer beide vormen van het endpoint** - Het pad `/wp-json/batch/v1` Beveiliging 30 jun 2026 [Everest Forms Pro kwetsbaarheid beveiligen: CVE-2026-3300](https://www.keurigonline.nl/blog/everest-forms-pro-kwetsbaarheid-beveiligen) 1. **Stel automatische updates in voor premium plugins.** Ga naar Plugins > Geïnstalleerde plugins en klik bij elke betaalde plugin op "Automatische updates inschakelen". Dit staat voor premium plugins vaak niet standaard aan en vereist een actieve licentieverbinding. 2. **Activeer een Web Application Firewall (WAF).** Wordfence (gratis basisversie beschikbaar) en Cloudflare blokkeren bekende aanvals-IP's en kwaadaardige payloads proactief, ook bij toekomstige kwetsbaarheden die nog niet gepatcht zijn. ### Wat als je site al gehackt is? Updaten naar 1.9.13 sluit de voordeur, maar richt de bestaande schade niet. Als je bij de controles uit het vorige onderdeel aanwijzingen hebt gevonden van een geslaagde aanval, doorloop dan de volgende stappen: