Web Application Firewall as a Service: So funktioniert WAF SaaS und wann sich Selbst-Hosting lohnt

Sie haben eine Web-App auf einem VPS. Das Access-Log zeigt Login-Versuche auf /wp-admin, Anfragen mit UNION SELECT im Query-String und stetigen Traffic aus Rechenzentrums-IP-Bereichen, die auf Ihrer Seite nichts verloren haben. Sie wollen den offensichtlichen Müll herausfiltern, bevor er Ihre Anwendung erreicht.

An diesem Punkt begegnen die meisten Leute zum ersten Mal dem Begriff WAF SaaS. Für viele Leser sind „die WAF" und „Cloudflare" dasselbe, weil Cloudflare das war, worauf sie zuerst gestoßen sind. Das ist nicht dasselbe. WAF SaaS ist eine Kategorie: eine aus der Cloud bereitgestellte Web Application Firewall, die Ihren HTTP-Traffic an der Edge des Anbieters prüft, bevor sie ihn an Ihren Origin weiterleitet. Cloudflare ist ein Produkt innerhalb dieser Kategorie.

Dieser Artikel zeigt, wie WAF SaaS funktioniert, was die großen Anbieter verlangen, wo es in der Praxis scheitert und wann eine eigene WAF auf einem Linux-VPS die bessere Option ist.

Kurzfassung

• WAF SaaS ist eine aus der Cloud bereitgestellte Web Application Firewall. Sie leiten Traffic über den Anbieter oder verknüpfen die WAF mit einer unterstützten Cloud-Ressource; der Dienst bewertet HTTP(S)-Anfragen, bevor die geschützte Anwendung sie verarbeitet.
• Die großen Anbieter nutzen drei grobe Preisformen: Abo-Stufen (Cloudflare und Sucuri), nutzungsbasierte Abrechnung (AWS WAF) und vertriebsgesteuerte Angebote (Imperva und Fastly). Nutzungsbasierte Kosten steigen mit den verarbeiteten Anfragen und optionalen Funktionen, während Abo-Pläne in der Regel besser planbar sind.
• Es gibt eine dokumentierte Kritik am WAF SaaS, und sie wird unten aufgegriffen. Sie zielt auf Latenz, False Positives, undurchsichtige Blockaden und das Routing von Daten über Dritte.
• Selbst gehostete WAFs auf einem VPS sind eine echte Option. SafeLine und BunkerWeb sind die beiden Open-Source-Projekte mit aktueller Dynamik. Sie laufen als Reverse Proxy vor Ihrer Anwendung.
• Gar keine WAF kann eine vertretbare Entscheidung sein, wenn die Anwendungssicherheit ausgereift ist, die Angriffsfläche kontrolliert wird, das Monitoring stark ist und das Restrisiko dokumentiert und akzeptiert wurde.

So funktioniert WAF SaaS

Eine Anfrage an example.com trifft zuerst auf die Edge des Anbieters, weil Ihr DNS dorthin zeigt. Der Edge-Knoten terminiert TLS, parst die HTTP-Anfrage, schickt sie durch eine Rule-Engine und leitet sie dann an Ihren Origin weiter, blockiert sie, stellt eine Challenge (CAPTCHA, JavaScript-Test) oder drosselt die Quelle. Bei der Weiterleitung sieht Ihre Anwendung die Anfrage so, als käme sie von der IP des Anbieters, wobei die ursprüngliche Client-IP in einem Header wie X-Forwarded-For oder CF-Connecting-IP mitgegeben wird.

Viele WAF-SaaS-Produkte nutzen einen vom Anbieter betriebenen Reverse Proxy oder eine Edge-Integration, aber nicht jeder Dienst wird über eine DNS-Änderung eingebunden. Cloudflare, Sucuri und Fastly sitzen üblicherweise an der Edge im Anfragepfad. AWS WAF wird mit CloudFront oder mit unterstützten AWS-Ressourcen wie Application Load Balancers, API-Gateway-APIs und AppSync-APIs verknüpft. In jedem Fall werden HTTP(S)-Anfragen geprüft, bevor die geschützte Anwendung sie verarbeitet.

Eine WAF prüft Layer-7-Daten wie Request-Header, Pfade, Query-Strings, Methoden, Cookies und den konfigurierten Teil der Request-Bodies. Eine klassische Netzwerk-Firewall entscheidet vor allem auf Layer 3 und 4 anhand von Adressen, Protokollen und Ports. Unser Leitfaden Hardware- vs. Software-Firewall behandelt die grundsätzliche Abgrenzung.

Managed WAF-Schutz speist sich in der Regel aus drei Regelquellen:

• Das OWASP Core Rule Set (CRS) ist eine Open-Source-Basis für ModSecurity und kompatible WAF-Engines. Es deckt gängige Angriffskategorien ab: SQL-Injection, Cross-Site-Scripting, Command Injection und Local File Inclusion. Produkte auf ModSecurity-Basis liefern CRS häufig mit, während viele Cloud-Anbieter stattdessen eigene Managed Rules einsetzen.
• Vom Anbieter gepflegte Regelsätze sind proprietäre Regeln, die der Anbieter aktuell hält. Cloudflares „Managed Rules", die „AWS Managed Rules" von AWS WAF und der Threat-Intelligence-Feed von Imperva fallen alle hierunter.
• Eigene Regeln sind die, die Sie selbst schreiben. „Blockiere Anfragen an /admin, die nicht aus diesem IP-Bereich kommen", „begrenze /api/login auf 5 pro Minute und IP".

Eine SQL-Injection-Regel kann ein bekanntes Muster wie ' OR 1=1 -- in einem Query-Parameter oder Request-Body erkennen. Das fängt faule Scans ab, aber eine WAF kann verschleierte Payloads, Logikfehler und bösartige Anfragen, die wie normaler Anwendungs-Traffic aussehen, trotzdem übersehen. Sie bewertet beobachtbare Request-Signale, nicht die fachliche Absicht.

Wogegen das schützt, im Klartext:

• Injection-Angriffe, deren Payload zu einer bekannten Signatur passt
• Bot-Traffic von bekannten Scannern
• Einfache Brute-Force-Muster
• Volumetrische DDoS, wenn der Anbieter auch DDoS-Scrubbing betreibt
• Einfacher API-Missbrauch

Was es nicht leistet:

• Ihre Anwendung patchen
• Die Eingabevalidierung in Ihrem Code ersetzen
• Angriffe stoppen, die wie normaler Traffic aussehen

Anwendungssicherheit entsteht weiterhin in der Anwendung. Eine WAF hebt den Boden gegen verbreitete und automatisierte Angriffe an, aber sicheres Coding, Patching, Autorisierung, Eingabeverarbeitung, Monitoring und Incident Response bestimmen die Decke.

WAF SaaS vs. On-Prem-Appliance vs. Selbst-Hosting auf einem VPS

2026 gibt es drei verbreitete WAF-Deployment-Modelle: Cloud-WAF-SaaS (Cloudflare, AWS WAF, Fastly und andere), physische oder virtuelle Appliances (darunter Angebote von F5 und Imperva) und selbst gehostete Software auf einem VPS oder Ihrem eigenen Server.

Die drei unterscheiden sich in vier praktischen Fragen: Wer betreibt die Inspection Plane, wer zahlt für Kapazität, wer tunt die Regeln, und was passiert, wenn die WAF etwas blockiert, das sie nicht hätte blockieren sollen. Der Rest des Artikels nutzt diese vier als Vergleichsraster.

Cloud-WAF SaaS

Sie leiten Traffic über die Edge des Anbieters oder verknüpfen die WAF mit einer unterstützten Cloud-Ressource. Der Anbieter betreibt Inspektionskapazität und Managed Updates, während Sie Regeln auswählen, anwendungsspezifische Policies anlegen und Ausnahmen tunen. Gängige Optionen sind Cloudflare, AWS WAF, Imperva, Sucuri und Fastly.

Der Kompromiss: Kapazität und Betrieb sind das Problem von jemand anderem. Jede HTTP-Anfrage läuft dafür auch über die Infrastruktur von jemand anderem. Ihr HTTP-Traffic passiert die Infrastruktur des Anbieters, und Request-Metadaten oder erkannte Payload-Ausschnitte können je nach Anbieter, Produkt und Logging-Einstellungen protokolliert werden.

On-Prem-Appliance-WAF

Eine physische oder virtuelle Appliance sitzt in Ihrem Netzwerkpfad. Käufer sind typischerweise Organisationen mit etabliertem Netzwerk-Security-Betrieb, festem Kapazitätsbedarf, strengen Deployment-Vorgaben oder bestehenden Herstellerbeziehungen. Kapazität, Upgrades, Hochverfügbarkeit und Tuning bleiben Sache des Kunden.

Für viele kleine und mittlere Teams machen Appliance-Beschaffung, feste Kapazität und Betriebsaufwand diesen Weg zum am wenigsten praktikablen. Für Organisationen, die eine Control Plane im eigenen Netz brauchen und Personal zum Betrieb haben, kann er trotzdem passen.

Selbst gehostete WAF auf Ihrem eigenen VPS

Sie installieren eine WAF auf einem Linux-VPS, richten Ihr DNS auf diesen VPS und die WAF sitzt als Reverse Proxy vor Ihrer Anwendung. Sie betreiben sie. Sie tunen sie. Sie loggen sich um 2 Uhr nachts ein, wenn ein Managed-Rule-Update eine legitime Anfrage blockiert und niemand sonst da ist, den man anrufen könnte.

Zwei Open-Source-Projekte haben aktuell Rückenwind: SafeLine, eine Open-Source-WAF mit semantischer Analyse-Engine statt reinem Regex-Matching, und BunkerWeb, eine NGINX-basierte WAF, die ModSecurity mitbringt. Lizenzen, Deployment-Modelle und Ressourcenbedarf folgen weiter unten im Abschnitt zum Selbst-Hosting.

Der Kompromiss ist die Umkehrung des SaaS-Modells. Sie kontrollieren Inspection Plane, Kapazität, Logs und Tuning. Das verringert die Abhängigkeit von einem externen WAF-Anbieter, aber Upstream-Netze und Hoster transportieren den Traffic weiterhin. Infrastrukturgrenzen, Bandbreite, Patching und Incident Response liegen jetzt bei Ihnen.

SaaS-WAF vs. selbst gehostete WAF auf Ihrem VPS

Die folgende Vergleichstabelle konzentriert sich auf die praktischen Unterschiede, die Sysadmins betreiben und einplanen müssen.

WAF-SaaS-Preise 2026

WAF-SaaS-Preise kombinieren meist Abo-Stufen, nutzungsabhängige Gebühren oder vertriebsgesteuerte Angebote. Öffentliche Preise sind nicht direkt vergleichbar, weil jeder Anbieter Managed Rules, Bot Controls, Logging, Support und DDoS-Funktionen anders bündelt.

AWS WAF veröffentlicht Preise pro Komponente, während Cloudflare und Sucuri Preise für Self-Service-Pläne veröffentlichen. Imperva und Fastly setzen für vergleichbare WAF-Angebote auf vertriebsgesteuerte Preise.

Stand 29. Juli 2026: die Cloudflare-Planübersicht nennt Pro mit 20 $ pro Monat bei jährlicher Zahlung oder 25 $ bei monatlicher, und Business mit 200 $ pro Monat jährlich oder 250 $ monatlich. Die Sucuri-Firewall-Preisseite 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 der AWS-WAF-Preisseite as of the same date.

Imperva und Fastly veröffentlichen keine direkt vergleichbaren Self-Service-WAF-Preise. Behandeln Sie beide daher als Contact-Sales-Optionen, statt sich auf Schätzungen Dritter zu verlassen.

Die AWS-WAF-Preisseite nennt Grundgebühren von 5 $ pro Web-ACL und Monat, 1 $ pro Regel oder Regelgruppe und Monat sowie 0,60 $ pro Million verarbeiteter Anfragen. Zusätzliche Gebühren können für mehr Kapazität, größere Body-Inspection, CAPTCHA- oder Challenge-Aktionen, Premium-Managed-Groups und Betrugs- oder Bot-Controls anfallen. Angriffs-Traffic kann die Rechnung also erhöhen, aber wie stark, hängt von Volumen, Dauer und aktivierten Funktionen ab. Rate-based Rules schützen die Anwendung; bereits verarbeitete WAF-Anfragen machen sie nicht kostenlos.

Wo WAF SaaS an Grenzen stößt

False Positives sind die erste praktische Grenze. Ein legitimer Upload, API-Aufruf oder Formular-Submit kann wie ein Angriffsmuster aussehen und eine Managed Rule auslösen. Der Betreiber muss dann die treffende Regel identifizieren, sie eingrenzen oder ausschließen und prüfen, dass die Ausnahme kein größeres Schlupfloch aufmacht.

WAFs entscheiden anhand von Request-Signalen, nicht anhand fachlicher Absicht. Strenge Regeln können legitimen Traffic blockieren; breite Ausnahmen können den Schutz schwächen. Cloud-Dienste bieten meist Event-Logs, Rule-Overrides und eigene Responses, aber wie viel Sichtbarkeit und Tuning zur Verfügung steht, hängt von Plan und Anbieter ab.

Profi-Tipp. Starten Sie neue oder wesentlich geänderte Regeln im Detection- oder Count-Modus. Beobachten Sie repräsentativen Traffic, testen Sie kritische und selten genutzte Workflows, gehen Sie False Positives durch und fügen Sie eng gefasste Ausschlüsse hinzu, bevor Sie Blocking aktivieren. Die aktuellen CRS-Tuning-Empfehlungen empfehlen ein bis zwei Wochen oder so lange, bis Spitzenlast und kritische Workflows einmal durchlaufen wurden.

Die zweite Grenze ist der Performance-Overhead. Ein ModSecurity-Benchmark von 2023 hat 9.462 Uploads kleiner Dateien mit aktivem CRS bei 7,36 Sekunden gemessen, ohne CRS bei 4,55 Sekunden. Der Durchsatz fiel von 2.079 auf 1.285 Anfragen pro Sekunde, während die nginx-CPU-Spitze von 8 % auf 73 % stieg. Das war eine einzige Konfiguration und ein einziger Workload. Nehmen Sie es als Beleg dafür, dass Inspektion etwas kostet, nicht als allgemeingültiges Sizing-Verhältnis.

Die dritte Grenze ist das Datenrouting. Jede HTTP-Anfrage, inklusive Request-Body, läuft durch die Infrastruktur des Anbieters. Bei Anwendungen, die personenbezogene Daten, Finanztransaktionen oder Gesundheitsdaten verarbeiten, ist das eine konkrete Frage der Datensouveränität. Eine in der EU gehostete Anwendung, die Kundenanfragen über einen US-Anbieter leitet, hat einen aufwendigeren Audit-Nachweis zu führen und ein paar zusätzliche Vertragsklauseln zu akzeptieren als dieselbe Anwendung mit einem selbst gehosteten Reverse Proxy auf einem VPS in derselben Jurisdiktion.

Die vierte Grenze ist der Tuning-Aufwand. Die Herausforderungen beim WAF-Tuning umfassen False Positives, begrenzten Anwendungskontext und Regeln, die mit häufigen Code-Änderungen Schritt halten müssen. Die Quelle ist eine Anbieterperspektive, aber das operative Muster ist real: Teams investieren entweder in kontinuierliches Tuning oder lassen mehr Regeln im reinen Detection-Modus.

Dieselbe Kritik von 2023 argumentiert, dass WAFs zu Security-Theater werden können, wenn Teams sich darauf verlassen, statt die Anwendung zu reparieren. Das Argument ist am stärksten bei Teams mit ausgereifter Anwendungssicherheit: parametrisierter Datenbankzugriff, saubere Autorisierung, regelmäßiges Dependency-Scanning, unveränderliche Deployments und wirksames Monitoring. In weniger reifen Umgebungen kann eine WAF die Angriffsfläche gegenüber verbreiteten automatisierten Scans trotzdem verringern. Beides kann zutreffen.

WAFs sind eine Schicht in einer Defense-in-Depth. Sie ersetzen keine Anwendungssicherheit, und sie sind auch kein Security-Theater. Der Grenznutzen einer WAF ist für manche Teams hoch und für andere gering. Entscheidend ist, wie die Anwendung darunter aussieht.

Wann Selbst-Hosting einer WAF sinnvoll ist

Selbst-Hosting gewinnt in drei Situationen. In drei anderen verliert es. Zuerst die Gewinnfälle.

Selbst-Hosting gewinnt, wenn Policy- oder Datensouveränitätsvorgaben die Inspektion durch einen externen WAF-SaaS-Vermittler ausschließen, wenn die Traffic-Muster nutzungsbasierte Preise unattraktiver machen als dedizierte Infrastruktur, und wenn ein Team direkte Kontrolle über Blocking-Entscheidungen und die Behebung von False Positives will.

Selbst-Hosting verliert, wenn keine Betriebskapazität da ist, wenn die Anwendung auf einer Managed Platform läuft, deren Routing-Modell einen externen Proxy umständlich macht, oder wenn ein anbieterverwalteter Free-Tier die benötigten Controls schon mit weniger Komplexität abdeckt.

Cloudflares Free-Plan kann ein praktischer Startpunkt für kleine und mittlere Teams sein, die ohnehin DNS oder CDN dort nutzen und das Modell der Traffic-Inspektion akzeptieren. Selbst-Hosting wird attraktiver, sobald Datenrouting, direkte Regelkontrolle oder planbare Infrastrukturkosten schwerer wiegen als möglichst wenig Betrieb.

SafeLine und BunkerWeb

Zwei selbst hostbare Open-Source-WAFs sollte man kennen.

SafeLine steht unter der Lizenz GPL-3.0, wird mit Docker Compose ausgerollt und setzt auf semantische Analyse statt auf ein reines CRS-Regelwerk. Das SafeLine-Repository meldet 71,65 % Erkennung, 0,07 % False Positives und 99,45 % Gesamtgenauigkeit im Balance-Modus über eine eigene Auswertung mit 33.669 Samples. Das sind Messungen der Projekt-Maintainer, kein unabhängiger Benchmark, und sie sollten nicht über diesen Testsatz hinaus verallgemeinert werden.

LESEN

So stellen Sie SafeLine WAF auf einem Linux-VPS bereit

BunkerWeb steht unter AGPL-3.0 und nutzt intern NGINX. Es integriert ModSecurity mit dem OWASP Core Rule Set und unterstützt mehrere Deployment-Modelle, darunter Linux, Docker, Swarm und Kubernetes.

Dimensionieren Sie beide Projekte anhand eines gemessenen Anfragevolumens, der aktivierten Schutzfunktionen, der TLS-Last und der Log-Aufbewahrung. Für ein SafeLine-Deployment mit wenig Traffic sind 2 vCPU und 4 GB RAM ein konservativer Startpunkt mit Luft über dem Installationsminimum. Die aktuelle BunkerWeb-Quickstart-Empfehlung empfiehlt mindestens 2 vCPU und 8 GB RAM für Tests oder sehr wenige Dienste und 4 vCPU mit 16 GB RAM für Produktionsumgebungen, die viele Dienste schützen. Der Speicher hängt vor allem von Log-Rate und Aufbewahrung ab: Messen Sie ihn, statt eine feste Anzahl Monate zu versprechen.

Profi-Tipp. Betreiben Sie die selbst gehostete WAF nach Möglichkeit in derselben Region wie den Origin der Anwendung. Ein entfernter Proxy fügt jeder Anfrage einen regionsübergreifenden Netzwerk-Roundtrip hinzu und kann die Latenz still verschlechtern. Messen Sie die End-to-End-Antwortzeit aus den Regionen Ihrer Nutzer, bevor Sie produktiv umschalten.

Sie betreiben die WAF selbst, also liegt auch die darunterliegende Infrastruktur bei Ihnen: Verfügbarkeit, Sicherheitspatches, TLS-Zertifikate, Backups, Log-Rotation, Monitoring, Kapazität und Wiederherstellung. Testen Sie das Verhalten im Fehlerfall ebenso sorgfältig wie die Filterregeln, damit die WAF nicht zum Single Point of Failure wird.

LESEN

Linux VPS absichern | 20 Wege, deinen VPS-Server zu sichern

Ein Entscheidungsrahmen

Es gibt vier Wege: Cloudflares Free-Tier, ein bezahltes Cloud-WAF-SaaS, eine selbst gehostete WAF auf einem VPS und gar keine WAF. Die Bedingung, die den jeweiligen Weg auswählt, ist jedes Mal eine andere.

Wählen Sie einen kostenlosen Cloud-WAF-Tier, wenn die verfügbaren Managed Rules und Limits zum Risiko der Anwendung passen, das Datenrouting-Modell akzeptabel ist und möglichst wenig Betriebsaufwand Priorität hat. Testen Sie echte Workflows, bevor Sie annehmen, dass die Defaults reichen.

Wählen Sie ein bezahltes WAF SaaS, wenn Sie mehr Managed Rules, Logging, eigene Controls, Bot- oder API-Schutz, Support oder Kapazität brauchen, als der Free-Tier liefert. Vergleichen Sie die genaue Feature- und Limit-Matrix, nicht nur den Plannamen. AWS WAF spielt seine Stärken aus, wenn die Anwendung bereits unterstützte AWS-Ressourcen nutzt und das Team komponentenbasierte Kosten souverän prognostiziert.

Wählen Sie eine selbst gehostete WAF, wenn die oben genannten Selbst-Hosting-Bedingungen zutreffen und Ihr Team den Proxy zuverlässig betreiben kann. SafeLine und BunkerWeb sind die beiden Projekte, die Sie zuerst prüfen sollten.

Gar keine WAF kann eine vertretbare Entscheidung sein, wenn die Anwendungssicherheit ausgereift ist, die Angriffsfläche bewusst kontrolliert wird, das Monitoring stark ist und das Restrisiko dokumentiert und akzeptiert wurde. Sie sollte nicht allein deshalb zum Standard werden, weil ein Framework Eingaben validiert.

Fazit

Wählen Sie WAF SaaS für anbieterseitig gemanagte Kapazität und weniger Betriebsaufwand. Wählen Sie Selbst-Hosting für direkte Kontrolle, wenn das Team den Proxy zuverlässig betreiben kann. In beiden Modellen gilt: Regeln stufenweise ausrollen, Latenz und False Positives messen, und Anwendungssicherheit an erster Stelle halten.

Wenn Selbst-Hosting zu Ihren Anforderungen passt, starten Sie mit einem Linux VPS in derselben Region wie der Origin. Cloudzy bietet außerdem Ein-Klick-Marketplace-Deployments für SafeLine und für BunkerWeb, damit Sie mit dem Testen beginnen können, ohne den Basis-Stack von Hand aufzubauen.

Häufig gestellte Fragen

Was ist WAF as a Service?

WAF as a Service ist eine aus der Cloud bereitgestellte Web Application Firewall. Der Traffic erreicht den Dienst über DNS- oder Reverse-Proxy-Routing, über eine Edge-Integration oder über die Verknüpfung mit einer unterstützten Cloud-Ressource. Der Anbieter betreibt Inspektionskapazität und Managed Updates; Sie wählen Policies, tunen Ausnahmen und ergänzen anwendungsspezifische Regeln.

Ist Cloudflare eine WAF?

Ja. Cloudflare bietet WAF-Funktionen als Teil einer breiteren Edge-Plattform, die auch DNS, CDN und DDoS-Schutz umfasst. Kostenlose Pläne erhalten das Cloudflare Free Managed Ruleset; umfangreichere Regelsätze, Controls, Analytics und Bot-Management hängen vom gewählten Plan und den Add-ons ab.

Reicht Cloudflares kostenlose WAF?

Das hängt von der Angriffsfläche der Anwendung ab, von den benötigten Regeln, den Logging- und Aufbewahrungsanforderungen, den API- oder Bot-Controls, den Supportanforderungen und Ihrer Toleranz für False Positives. Das Free Managed Ruleset kann eine brauchbare Basis sein, aber Authentifizierung, Zahlungen oder regulierte Daten führen nicht automatisch zu einem bestimmten kostenpflichtigen Plan. Vergleichen Sie die aktuellen Feature-Limits und prüfen Sie sie gegen Ihr Bedrohungsmodell.

Was ist der Unterschied zwischen einer WAF und einer Firewall?

Eine klassische Netzwerk-Firewall filtert Traffic vor allem anhand von Layer-3- und Layer-4-Informationen: Adressen, Protokolle und Ports. Eine WAF bewertet HTTP(S)-Anfragen auf Layer 7, inklusive der konfigurierten Header, Pfade, Parameter und Body-Inhalte. Moderne Sicherheitsprodukte verwischen diese Grenzen manchmal, aber die beiden Controls bleiben komplementär statt austauschbar.

Was ist WAAP und wie unterscheidet es sich von einer WAF?

WAAP steht für Web Application and API Protection. Es ist breiter als eine klassische WAF: Anbieter kombinieren dabei meist WAF-Regeln mit API-Discovery oder -Enforcement, Bot-Management und anwendungsnahen DDoS- oder Missbrauchs-Controls. Was genau im Bundle steckt, unterscheidet sich je Anbieter, WAAP sollte also nicht als standardisierter Funktionsumfang verstanden werden.

Brauche ich eine WAF, wenn mein Framework die Eingaben schon validiert?

Nicht immer. Framework-Controls senken das Risiko, decken aber nicht jedes Muster automatisierten Missbrauchs ab. Ergänzen Sie eine WAF nur dann, wenn sie ein konkret benanntes Risiko adressiert, das ihre Kosten und ihren Tuning-Aufwand rechtfertigt.