Je hebt een webapp op een VPS. Het accesslog toont inlogpogingen op /wp-admin, requests met UNION SELECT in de querystring en gestaag verkeer uit datacenter-IP-reeksen die niets op je site te zoeken hebben. Je wilt de duidelijke rommel filteren voordat die je applicatie bereikt.
Dit is het moment waarop de meeste mensen de term WAF SaaS tegenkomen. Voor veel lezers zijn 'de WAF' en 'Cloudflare' hetzelfde, omdat Cloudflare is wat ze als eerste tegenkwamen. Ze zijn niet hetzelfde. WAF SaaS is een categorie: een web application firewall vanuit de cloud die je HTTP-verkeer aan de edge van de provider inspecteert voordat het naar je origin gaat. Cloudflare is één product binnen die categorie.
Dit artikel loopt door hoe WAF SaaS werkt, wat de grote aanbieders rekenen, waar het in de praktijk misgaat, en wanneer een eigen WAF op een Linux-VPS de betere keuze is.
TL;DR
- WAF SaaS is een web application firewall vanuit de cloud. Je routeert verkeer via de provider of koppelt de WAF aan een ondersteunde cloudresource; de dienst beoordeelt HTTP(S)-requests voordat de beschermde applicatie ze verwerkt.
- De grote aanbieders gebruiken drie brede prijsvormen: abonnementsniveaus (Cloudflare en Sucuri), verbruiksfacturatie (AWS WAF) en offertes via sales (Imperva en Fastly). Verbruikskosten stijgen met verwerkte requests en optionele functies, terwijl abonnementen doorgaans voorspelbaarder zijn.
- Er bestaat een gedocumenteerde kritiek op WAF SaaS, en die komt hieronder aan bod. Ze wijst op latency, false positives, ondoorzichtige blokkades en dataroutering via derden.
- Zelf gehoste WAF's op een VPS zijn een reële optie. SafeLine en BunkerWeb zijn de twee opensourceprojecten met momentum. Ze draaien als reverse proxy vóór je applicatie.
- Geen WAF kan een verdedigbare keuze zijn als de applicatiebeveiliging volwassen is, de blootstelling beheerst wordt, de monitoring sterk is en het resterende risico gedocumenteerd en geaccepteerd is.
Hoe WAF SaaS werkt
Een request naar example.com komt eerst bij de edge van de provider, omdat je DNS daarheen wijst. De edge-node termineert TLS, parseert het HTTP-request, haalt het door een rule engine en stuurt het vervolgens door naar je origin, blokkeert het, geeft een challenge (CAPTCHA, JavaScript-test) of knijpt de bron af. Bij doorsturen ziet je applicatie het request alsof het van het IP van de provider kwam, met het oorspronkelijke client-IP in een header als X-Forwarded-For of CF-Connecting-IP.
Veel WAF SaaS-producten gebruiken een door de provider beheerde reverse proxy of een edge-integratie, maar niet elke dienst wordt via een DNS-wijziging uitgerold. Cloudflare, Sucuri en Fastly zitten doorgaans in het requestpad, aan de edge. AWS WAF wordt gekoppeld aan CloudFront of aan ondersteunde AWS-resources zoals Application Load Balancers, API Gateway-API's en AppSync-API's. In alle gevallen worden HTTP(S)-requests beoordeeld voordat de beschermde applicatie ze verwerkt.
Een WAF inspecteert laag 7-data zoals requestheaders, paden, querystrings, methodes, cookies en het ingestelde deel van de request bodies. Een klassieke netwerkfirewall beslist vooral op laag 3 en 4 op basis van adressen, protocollen en poorten. Onze gids hardware- versus softwarefirewall behandelt het bredere onderscheid.
Managed WAF-bescherming put doorgaans uit drie regelbronnen:
- De OWASP Core Rule Set (CRS) is een opensourcebasis voor ModSecurity en compatibele WAF-engines. Het dekt veelvoorkomende aanvalscategorieën als SQL-injectie, cross-site scripting, command injection en local file inclusion. Producten rond ModSecurity leveren CRS vaak mee, terwijl veel cloudaanbieders eigen managed rules gebruiken.
- Door de leverancier beheerde regelsets zijn propriëtaire regels die de provider actueel houdt. Cloudflares 'Managed Rules', de 'AWS Managed Rules' van AWS WAF en de threat-intelligencefeed van Imperva vallen hier allemaal onder.
- Eigen regels zijn de regels die je zelf schrijft. 'Blokkeer requests naar /admin die niet uit deze IP-reeks komen', 'beperk /api/login tot 5 per minuut per IP'.
Een SQL-injectieregel kan een bekend patroon als ' OR 1=1 -- in een queryparameter of request body markeren. Dat vangt luie scans, maar een WAF kan nog steeds geobfusceerde payloads, logicafouten en kwaadaardige requests missen die op normaal applicatieverkeer lijken. Hij beoordeelt waarneembare requestsignalen, geen zakelijke intentie.
Waartegen dit beschermt, in gewone taal:
- Injectieaanvallen waarvan de payload met een bekende signature matcht
- Botverkeer van bekende scanners
- Eenvoudige brute-forcepatronen
- Volumetrische DDoS, als de provider ook DDoS-scrubbing draait
- Basaal API-misbruik
Wat het niet doet:
- Je applicatie patchen
- De invoervalidatie in je code vervangen
- Aanvallen stoppen die op normaal verkeer lijken
Applicatiebeveiliging komt nog steeds uit de applicatie. Een WAF tilt de bodem op tegen veelvoorkomende en geautomatiseerde aanvallen, maar veilig programmeren, patchen, autorisatie, invoerafhandeling, monitoring en incidentrespons bepalen het plafond.
WAF SaaS versus on-premise appliance versus zelf hosten op een VPS
In 2026 zijn er drie gangbare WAF-deploymentmodellen: cloud-WAF SaaS (Cloudflare, AWS WAF, Fastly en anderen), fysieke of virtuele appliances (waaronder aanbod van F5 en Imperva), en zelf gehoste software op een VPS of je eigen server.
De drie verschillen op vier praktische vragen: wie draait het inspectievlak, wie betaalt de capaciteit, wie tunet de regels, en wat gebeurt er als de WAF iets blokkeert dat niet geblokkeerd had mogen worden. De rest van het artikel gebruikt deze vier als vergelijkingskader.
Cloud-WAF SaaS
Je routeert verkeer via de edge van de provider of koppelt de WAF aan een ondersteunde cloudresource. De provider draait de inspectiecapaciteit en de managed updates, terwijl jij regels kiest, applicatiespecifieke policies maakt en uitzonderingen tunet. Gangbare opties zijn Cloudflare, AWS WAF, Imperva, Sucuri en Fastly.
De afweging: capaciteit en beheer zijn andermans probleem. Maar elk HTTP-request loopt ook door andermans infrastructuur. Je HTTP-verkeer gaat door de infrastructuur van de provider, en requestmetadata of gematchte payloadfragmenten kunnen worden gelogd, afhankelijk van provider, product en logginginstellingen.
On-premise appliance-WAF
Een fysieke of virtuele appliance staat in je netwerkpad. Kopers zijn doorgaans organisaties met gevestigde netwerkbeveiligingsoperaties, vaste capaciteitseisen, strikte deploymentcontroles of bestaande leveranciersrelaties. Capaciteit, upgrades, hoge beschikbaarheid en tuning blijven de verantwoordelijkheid van de klant.
Voor veel kleine en middelgrote teams maken de aanschaf van een appliance, de vaste capaciteit en de beheerslast dit de minst praktische route. Voor organisaties die een control plane binnen het netwerk nodig hebben en er personeel voor hebben, kan het nog steeds passen.
Zelf gehoste WAF op je eigen VPS
Je installeert een WAF op een Linux-VPS, wijst je DNS naar die VPS, en de WAF staat als reverse proxy vóór je applicatie. Jij draait hem. Jij tunet hem. Jij logt om 2 uur 's nachts in als een managed rule-update een legitiem request blokkeert en er niemand anders is om te bellen.
Twee opensourceprojecten hebben momentum: SafeLine, een opensource-WAF met een semantische analyse-engine in plaats van pure regex-matching, en BunkerWeb, een op NGINX gebaseerde WAF die ModSecurity meelevert. Hun licenties, deploymentmodellen en resourcegebruik komen verderop aan bod, in de sectie over zelf hosten.
De afweging is het spiegelbeeld van het SaaS-model. Jij hebt controle over het inspectievlak, de capaciteit, de logs en de tuning. Dat vermindert de afhankelijkheid van een externe WAF-provider, maar upstreamnetwerken en hosters vervoeren het verkeer nog steeds. Infrastructuurlimieten, bandbreedte, patchen en incidentrespons zijn nu jouw verantwoordelijkheid.
SaaS-WAF versus zelf gehoste WAF op je VPS
De vergelijkingstabel hieronder richt zich op de praktische verschillen die sysadmins moeten beheren en begroten.
| Criteria | Cloud-SaaS-WAF | Zelf gehoste WAF op een VPS |
|---|---|---|
| Wie het inspectievlak draait | De provider, aan de netwerkedge | Jij, op je VPS |
| Wie de capaciteit betaalt | De provider, aan jou doorberekend per abonnement of per request | Jij, vaste kosten van de VPS |
| Wie de regels tunet | Jij configureert; de provider levert de managed rule-updates | Jij, van begin tot eind |
| Verhaal bij false positives | Regels en uitzonderingen tunen binnen de controls van de provider; platformproblemen escaleren | De regel zelf aanpassen; binnen minuten opnieuw uitrollen |
| Dataroutering | Requests gaan door de inspectie-infrastructuur van de provider | Requests gaan door infrastructuur die jij beheert voordat ze de origin bereiken |
| Hoe de kosten zich gedragen bij een verkeerspiek | Verbruiksafhankelijke componenten kunnen stijgen met het requestvolume | Meestal voorspelbaarder, maar bandbreedte en opschalen kunnen alsnog kosten opleveren |
| Operationele belasting | Laag, beperkt tot configuratie en tuning | Jij draait de VPS én de WAF |
WAF SaaS-prijzen in 2026
WAF SaaS-prijzen combineren meestal abonnementsniveaus, verbruikskosten of offertes via sales. Publieke prijzen zijn niet direct vergelijkbaar, omdat elke aanbieder managed rules, botcontrols, logging, support en DDoS-functies anders bundelt.
| Leverancier | Prijsmodel | Instapprijs | Wat het instapniveau bevat | Opmerkingen |
|---|---|---|---|---|
| Cloudflare | Abonnementsniveau | Gratis; Pro $20/mnd jaarlijks of $25/mnd maandelijks; Business $200/mnd jaarlijks of $250/mnd maandelijks | Free Managed Ruleset; bredere controls verschillen per betaald plan | Controleer de actuele regels, limieten en meegeleverde beveiligingsfuncties vóór aankoop |
| AWS WAF | Per request | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Zelfbeheerde regels; AWS Managed Rules kunnen als managed rule groups worden toegevoegd | Extra capaciteit, body-inspectie, premium managed groups, CAPTCHA, Challenge, Bot Control en Fraud Control kunnen kosten toevoegen |
| Imperva | Enterprise-offerte | Neem contact op met verkoop | Managed rules, threat intelligence en API-securityopties | Geen direct vergelijkbare publieke selfservice-WAF-prijs |
| Sucuri Platform | Abonnementsniveau | Basic Firewall $9,99/mnd; Basic Platform $229/jaar | Firewallplan: WAF/CDN; de Platform-bundel voegt scanning en opschoning toe | De losse firewall en de jaarlijkse Platform-bundel zijn verschillende producten |
| Fastly | Via sales | Neem contact op met verkoop | Edge- of gedistribueerde inspectie, managed rules en API-bescherming | Geen direct vergelijkbare publieke selfservice-WAF-prijs |
AWS WAF publiceert prijzen per component, terwijl Cloudflare en Sucuri prijzen van selfserviceplannen publiceren. Imperva en Fastly hanteren salesgestuurde prijzen voor vergelijkbaar WAF-aanbod.
Gecontroleerd op 29 juli 2026: de Cloudflare-prijspagina noemt Pro op $20 per maand bij jaarfacturatie of $25 bij maandfacturatie, en Business op $200 per maand jaarlijks of $250 maandelijks. De Sucuri-firewallprijspagina lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from de AWS WAF-prijzen as of the same date.
Imperva en Fastly publiceren geen direct vergelijkbare selfservice-WAF-prijzen, dus behandel beide als contact-sales-opties in plaats van te vertrouwen op schattingen van derden.
De AWS WAF-prijspagina noemt basiskosten van $5 per web-ACL per maand, $1 per regel of regelgroep per maand en $0,60 per miljoen verwerkte requests. Er kunnen extra kosten gelden voor extra capaciteit, ruimere body-inspectie, CAPTCHA- of Challenge-acties, premium managed groups en fraude- of botcontrols. Aanvalsverkeer kan de rekening dus verhogen, maar hoeveel hangt af van volume, duur en ingeschakelde functies. Rate-based rules beschermen de applicatie; ze maken al verwerkte WAF-requests niet gratis.
Waar WAF SaaS tekortschiet
False positives zijn de eerste praktische beperking. Een legitieme upload, API-call of formulierinzending kan op een aanvalspatroon lijken en een managed rule triggeren. De beheerder moet dan de matchende regel opzoeken, hem versmallen of uitsluiten, en nagaan dat de uitzondering geen bredere bypass oplevert.
WAF's beslissen op basis van requestsignalen, niet op zakelijke intentie. Strenge regels kunnen legitiem verkeer blokkeren; brede uitzonderingen kunnen de bescherming verzwakken. Clouddiensten bieden meestal eventlogs, rule-overrides en eigen responses, maar hoeveel zichtbaarheid en tuning je krijgt, verschilt per plan en aanbieder.
Pro-tip. Start nieuwe of ingrijpend gewijzigde regels in detection- of count-modus. Bekijk representatief verkeer, test kritieke én zelden gebruikte workflows, loop de false positives na en voeg strak afgebakende uitsluitingen toe voordat je blokkeren aanzet. De huidige CRS-tuningrichtlijnen adviseren één tot twee weken, of tot piekverkeer en kritieke workflows zijn doorlopen.
De tweede beperking is performanceoverhead. Een ModSecurity-benchmark uit 2023 mat 9.462 uploads van kleine bestanden in 7,36 seconden met CRS aan tegenover 4,55 seconden zonder. De doorvoer zakte van 2.079 naar 1.285 requests per seconde, terwijl de piek-CPU van nginx opliep van 8 % naar 73 %. Dit was één configuratie en één workload, dus gebruik het als bewijs dat inspectie iets kost, niet als universele sizingverhouding.
De derde beperking is dataroutering. Elk HTTP-request, inclusief request body, gaat door de infrastructuur van de provider. Voor applicaties die persoonsgegevens, financiële transacties of medische data verwerken, is dat een concrete vraag over datasoevereiniteit. Een in de EU gehoste applicatie die klantrequests via een Amerikaanse WAF-provider routeert, moet een zwaarder audit spoor verantwoorden en een paar extra contractuele voorwaarden accepteren dan diezelfde applicatie met een zelf gehoste reverse proxy op een VPS in dezelfde jurisdictie.
De vierde beperking is de tuninglast. De uitdagingen van WAF-tuning omvatten false positives, beperkte applicatiecontext en regels die frequente codewijzigingen moeten bijbenen. De bron is een leveranciersperspectief, maar het operationele patroon is echt: teams investeren óf in continue tuning, óf ze laten meer regels in detection-only staan.
Dezelfde kritiek uit 2023 stelt dat WAF's securitytheater kunnen worden als teams erop leunen in plaats van de applicatie te repareren. Dat argument is het sterkst voor teams met volwassen applicatiebeveiliging: geparametriseerde databasetoegang, stevige autorisatie, regelmatige dependency scanning, immutable deployments en effectieve monitoring. In minder volwassen omgevingen kan een WAF de blootstelling aan gangbare geautomatiseerde scans nog steeds verkleinen. Beide punten kunnen waar zijn.
WAF's zijn één laag in defense in depth. Ze vervangen applicatiebeveiliging niet, en ze zijn ook geen securitytheater. De marginale waarde van een WAF is hoog voor sommige teams en laag voor andere. Wat de doorslag geeft, is hoe de applicatie eronder eruitziet.
Wanneer een WAF zelf hosten zin heeft
Zelf hosten wint in drie situaties. In drie andere verliest het. Eerst de winnaars.
Zelf hosten wint als beleid of datasoevereiniteit inspectie door een externe WAF SaaS-tussenpartij uitsluit, als de verkeerspatronen verbruiksprijzen minder aantrekkelijk maken dan eigen infrastructuur draaien, en als een team directe controle wil over blokkeerbeslissingen en het oplossen van false positives.
Zelf hosten verliest als er geen beheercapaciteit is, als de applicatie op een managed platform draait waarvan het routeringsmodel een externe proxy lastig maakt, of als een gratis tier van de provider de vereiste controls al met minder complexiteit dekt.
Het gratis plan van Cloudflare kan een praktisch startpunt zijn voor kleine en middelgrote teams die er al DNS of CDN afnemen en het inspectiemodel accepteren. Zelf hosten wordt aantrekkelijker zodra dataroutering, directe regelcontrole of voorspelbare infrastructuurkosten zwaarder wegen dan zo weinig mogelijk beheerwerk.
SafeLine en BunkerWeb
Twee zelf te hosten opensource-WAF's zijn het kennen waard.
SafeLine staat onder GPL-3.0, wordt uitgerold met Docker Compose en is gebouwd rond semantische analyse in plaats van een pure CRS-ruleset. De SafeLine-repository meldt 71,65 % detectie, 0,07 % false positives en 99,45 % totale nauwkeurigheid in Balance-modus, over een eigen evaluatie met 33.669 samples. Dit zijn metingen van de projectonderhouders, geen onafhankelijke benchmark, en ze mogen niet verder worden veralgemeend dan die testset.
BunkerWeb staat onder AGPL-3.0 en gebruikt NGINX onder de motorkap. Het integreert ModSecurity met de OWASP Core Rule Set en ondersteunt meerdere deploymentmodellen, waaronder Linux, Docker, Swarm en Kubernetes.
Dimensioneer beide projecten op basis van een gemeten requestvolume, de ingeschakelde beschermingen, het TLS-werk en de logretentie. Voor een SafeLine-deployment met weinig verkeer zijn 2 vCPU en 4 GB RAM een behoudend startpunt, met ruimte boven het installatieminimum. De huidige BunkerWeb-quickstartrichtlijn adviseert minstens 2 vCPU en 8 GB RAM voor tests of heel weinig services, en 4 vCPU met 16 GB RAM voor productieomgevingen die veel services beschermen. Opslag hangt vooral af van logsnelheid en retentie: meet het in plaats van een vast aantal maanden te beloven.
Pro-tip. Draai de zelf gehoste WAF waar mogelijk in dezelfde regio als de origin van de applicatie. Een verre proxy voegt per request een interregionale netwerk-roundtrip toe en kan de latency stilletjes verslechteren. Meet de end-to-endresponstijd vanuit de regio's van je gebruikers vóór de productieomschakeling.
Jij draait de WAF zelf, en dus is de onderliggende infrastructuur ook jouw verantwoordelijkheid: uptime, securitypatches, TLS-certificaten, back-ups, logrotatie, monitoring, capaciteit en herstel. Test het gedrag bij storingen net zo zorgvuldig als de filterregels, zodat de WAF geen single point of failure wordt.
Een Besluitvormingskader
Er zijn vier wegen: het gratis niveau van Cloudflare, een betaalde cloud-WAF SaaS, een zelf gehoste WAF op een VPS, en helemaal geen WAF. De voorwaarde die elk van die wegen aanwijst, is telkens anders.
Kies een gratis cloud-WAF-tier als de beschikbare managed rules en limieten passen bij het risico van de applicatie, het datarouteringsmodel acceptabel is en zo min mogelijk beheerwerk de prioriteit is. Test echte workflows voordat je aanneemt dat de defaults volstaan.
Kies een betaalde WAF SaaS als je meer managed rules, logging, eigen controls, bot- of API-bescherming, support of capaciteit nodig hebt dan het gratis niveau biedt. Vergelijk de precieze feature- en limietmatrix, niet alleen de plannaam. AWS WAF is het sterkst als de applicatie al ondersteunde AWS-resources gebruikt en het team componentgebaseerde kosten prima kan inschatten.
Kies een zelf gehoste WAF als de eerder genoemde zelfhostingvoorwaarden gelden en je team de proxy betrouwbaar kan draaien. SafeLine en BunkerWeb zijn de twee projecten om als eerste te beoordelen.
Geen WAF kan een verdedigbare keuze zijn als de applicatiebeveiliging volwassen is, de blootstelling bewust beheerst wordt, de monitoring sterk is en het restrisico gedocumenteerd en geaccepteerd is. Het mag niet de standaardkeuze worden alleen omdat een framework invoer valideert.
Conclusie
Kies WAF SaaS voor door de provider beheerde capaciteit en minder beheerlast. Kies zelf hosten voor directe controle, als het team de proxy betrouwbaar kan draaien. In beide modellen geldt: rol regels gefaseerd uit, meet latency en false positives, en houd applicatiebeveiliging voorop.
Als zelf hosten bij je eisen past, begin dan met een Linux VPS in dezelfde regio als de origin. Cloudzy biedt ook marketplace-deployments met één klik voor SafeLine en voor BunkerWeb, zodat je kunt beginnen met testen zonder de basisstack met de hand op te bouwen.
Bouw op een Linux VPS met root-toegang, NVMe en AMD EPYC-kracht.
Bekijk Linux-plannenVeelgestelde vragen
Wat is WAF as a service?
WAF as a service is een web application firewall vanuit de cloud. Het verkeer bereikt de dienst via DNS- of reverseproxyroutering, via een edge-integratie, of via koppeling aan een ondersteunde cloudresource. De provider draait de inspectiecapaciteit en de managed updates; jij kiest policies, tunet uitzonderingen en voegt applicatiespecifieke regels toe.
Is Cloudflare een WAF?
Ja. Cloudflare levert WAF-functionaliteit als onderdeel van een breder edge-platform dat ook DNS, CDN en DDoS-bescherming omvat. Gratis plannen krijgen de Cloudflare Free Managed Ruleset; bredere rulesets, controls, analytics en botmanagement hangen af van het gekozen plan en de add-ons.
Is de gratis WAF van Cloudflare genoeg?
Dat hangt af van het aanvalsoppervlak van de applicatie, de vereiste regels, de logging- en retentiebehoefte, API- of botcontrols, supporteisen en je tolerantie voor false positives. De Free Managed Ruleset kan een bruikbare basis zijn, maar authenticatie, betalingen of gereguleerde data vertalen zich niet automatisch naar één specifiek betaald plan. Vergelijk de actuele featurelimieten en toets ze aan je threat model.
Wat is het verschil tussen een WAF en een firewall?
Een klassieke netwerkfirewall filtert verkeer vooral op laag 3- en laag 4-informatie: adressen, protocollen en poorten. Een WAF beoordeelt HTTP(S)-requests op laag 7, inclusief de ingestelde headers, paden, parameters en bodyinhoud. Moderne securityproducten kunnen die grenzen vervagen, maar de twee controls blijven complementair in plaats van uitwisselbaar.
Wat is WAAP en hoe verschilt het van een WAF?
WAAP staat voor Web Application and API Protection. Het is breder dan een klassieke WAF: leveranciers combineren doorgaans WAF-regels met API-discovery of -enforcement, botmanagement en DDoS- of misbruikcontroles op applicatieniveau. Wat er precies in de bundel zit, verschilt per aanbieder, dus WAAP is geen gestandaardiseerde featureset.
Heb ik een WAF nodig als mijn framework de invoer al valideert?
Niet altijd. Framework-controls verkleinen het risico, maar dekken niet elk patroon van geautomatiseerd misbruik. Voeg een WAF alleen toe als die een concreet benoemd risico afdekt dat de kosten en de tuning rechtvaardigt.
