Eine WAF schützt Webanwendungen, indem sie HTTP-Anfragen auf Angriffsmuster wie SQL-Injection oder Cross-Site-Scripting prüft und verdächtige Anfragen blockiert, bevor sie die Anwendung erreichen.
Eine Web Application Firewall (WAF) sitzt zwischen dem Internet und einer Webanwendung oder API und untersucht jede HTTP-Anfrage auf Anwendungsebene. Anders als eine klassische Firewall, die Adressen und Ports prüft, versteht die WAF den Inhalt: Parameter, Header, Cookies, Formularfelder. Erkennt sie Muster bekannter Angriffe wie SQL-Injection, Cross-Site-Scripting oder Pfadmanipulation, blockiert sie die Anfrage oder protokolliert sie, je nach Betriebsmodus.
Moderne Produkte bündeln WAF, Bot-Abwehr, API-Schutz und DDoS-Schutz unter dem Begriff WAAP (Web Application and API Protection) und werden häufig als Cloud-Dienst vor die Anwendung geschaltet.
So funktioniert eine WAF
- Signaturen und Regelwerke: Vordefinierte Regeln, etwa das OWASP Core Rule Set, erkennen bekannte Angriffsmuster in Anfragen.
- Positivmodell: Die WAF lernt oder erhält eine Beschreibung des erlaubten Verhaltens (zulässige Pfade, Parameter, Datentypen) und blockiert alles Abweichende. Aufwendiger, aber deutlich wirksamer.
- Verhaltensanalyse: Ratenbegrenzung, Erkennung automatisierter Zugriffe und von Credential Stuffing, Bot-Klassifizierung.
- Virtuelles Patchen: Eine neu bekannt gewordene Schwachstelle in der Anwendung wird mit einer WAF-Regel abgefangen, bis der eigentliche Fix bereitsteht.
- Betriebsmodi: Im Überwachungsmodus werden Treffer nur protokolliert, im Blockiermodus abgewiesen. Viele Installationen verbleiben dauerhaft im ersten Modus.
Bedeutung für Unternehmen
Webanwendungen und APIs sind die exponierteste Fläche eines Unternehmens, und Schwachstellen darin gehören laut OWASP Top 10 seit Jahren zu den häufigsten Risiken. Laut Mandiant M-Trends 2026 waren Exploits mit 32 Prozent der häufigste Erstzugriff. Eine WAF senkt das Risiko, indem sie automatisierte Angriffe und bekannte Muster abfängt, und verschafft Zeit, wenn eine Schwachstelle bekannt wird, bevor der Patch eingespielt ist. Für Zahlungsanwendungen ist sie unter PCI DSS 4.0 eine anerkannte Maßnahme.
Was wir in Einsätzen sehen: Die WAF ist vorhanden, läuft aber im Überwachungsmodus, weil beim Umschalten legitime Anfragen blockiert wurden und niemand die Zeit für das Feintuning hatte. Oder sie ist nur vor der Hauptanwendung geschaltet, während ältere Portale, Test-Instanzen und direkt erreichbare Ursprungsserver ungeschützt bleiben. Signaturbasierte Regeln lassen sich zudem durch Variationen der Anfrage umgehen; eine WAF erschwert einen gezielten Angriff, verhindert ihn aber nicht. Die eigentliche Schwachstelle in der Anwendung bleibt bestehen.
Praxis: Umsetzung und Prüfung
- WAF als zusätzliche Schicht, nicht als Ersatz: Sichere Entwicklung, Code-Reviews und regelmäßige Tests der Anwendung bleiben die Grundlage. Die WAF fängt auf, was durchrutscht.
- Blockiermodus erreichen: Beginnen Sie mit Hochkonfidenz-Regeln im Blockiermodus und erweitern Sie schrittweise. Ein dauerhaft nur protokollierender Betrieb schützt nicht.
- Ursprungsserver abschotten: Die Anwendung darf nur über die WAF erreichbar sein; direkte Zugriffe auf den Ursprungsserver werden gesperrt. Sonst umgeht ein Angreifer die WAF durch einfachen Wechsel der Zieladresse.
- Logs anbinden: WAF-Treffer gehören ins SIEM; gehäufte Treffer auf einer Anwendung sind ein Frühindikator für einen gezielten Angriff.
- Mit und ohne WAF testen: Im Penetrationstest prüfen wir die Anwendung zunächst hinter der WAF und anschließend direkt, um Schwachstellen in der Anwendung von der Wirkung der WAF zu trennen. Beide Befunde gehören in den Bericht: Die WAF-Umgehung zeigt, wo die Regeln nachgeschärft werden müssen, die Anwendungslücke, was tatsächlich behoben werden muss.