WAF (Web Application Firewall) – Empfohlener Schutz für Webanwendungen & APIs

In Kundenprojekten erleben wir regelmäßig, dass Unternehmen ihre Netzwerksicherheit mit Next-Generation Firewalls und Endpoint-Lösungen solide aufgestellt haben, aber ihre Webanwendungen und APIs nahezu ungeschützt im Internet erreichbar sind. Das Problem dabei ist simpel. Klassische Firewalls arbeiten auf Netzwerk- und Transportebene und sind blind für Angriffe, die direkt auf die Anwendungsschicht zielen. Genau hier setzt eine Web Application Firewall (WAF) an. Angesichts der aktuellen Bedrohungslage (Akamai dokumentierte allein 2024 weltweit 311 Milliarden Angriffe auf Webanwendungen, ein Plus von 33 Prozent) ist die Frage nicht mehr ob, sondern wie schnell Unternehmen mit extern erreichbaren Anwendungen diesen Schutz umsetzen.

Was genau macht eine WAF – und was nicht?

Eine Web Application Firewall sitzt als Schutzschicht zwischen dem Internet und einer Webanwendung. Sie analysiert den HTTP- und HTTPS-Datenverkehr auf Anwendungsebene (Layer 7 im OSI-Modell) und erkennt Angriffsversuche, die auf Schwachstellen in der Anwendung selbst abzielen. Im Kern arbeitet eine WAF als Reverse Proxy, das heißt jede Anfrage an die Webanwendung wird zuerst von der WAF geprüft, bevor sie den eigentlichen Webserver erreicht.

Was eine WAF blockiert, sind typische Angriffsmuster auf Anwendungsebene. Dazu gehören SQL-Injections, bei denen Angreifer über manipulierte Eingabefelder Datenbankabfragen einschleusen. Ebenso Cross-Site-Scripting (XSS), bei dem schädlicher JavaScript-Code in die Anwendung eingebettet wird. Weitere Bedrohungen sind Session Hijacking, Directory Traversal und API-Missbrauch. Moderne WAFs erkennen diese Muster über eine Kombination aus Signaturen, Verhaltensanalyse und zunehmend auch maschinellem Lernen.

Das macht eine Web Application Firewall nicht

In der Praxis erleben wir hier regelmäßig Missverständnisse. Eine WAF ersetzt keine Netzwerk-Firewall und kein Intrusion Prevention System (IPS). Umgekehrt schützen Netzwerk-Firewalls und IPS nicht vor Angriffen, die innerhalb einer validen HTTP-Verbindung stattfinden. Wer einen Webshop betreibt und nur eine Netzwerk-Firewall hat, ist für SQL-Injection blind. Die Anfrage kommt über Port 443, sieht auf Transportebene völlig normal aus und enthält den eigentlichen Angriff erst in den Anwendungsdaten.

Eine WAF schützt auch nicht vor volumetrischen DDoS-Angriffen auf Netzwerkebene (Layer 3/4) und ersetzt keine sichere Softwareentwicklung. Sie ist ein Sicherheitsnetz, kein Freibrief für unsauberen Code.

Brauche ich eine WAF? 5 Fragen zur Entscheidung

In der Beratung erleben wir regelmäßig, dass WAF als „nice to have" eingestuft wird, bis der erste Vorfall eintritt. Statt pauschal „Ja, jeder braucht eine WAF" zu sagen, helfen diese fünf Fragen bei einer ehrlichen Einschätzung.

1. Betreibe ich Webanwendungen, die aus dem Internet erreichbar sind?

Gemeint sind Webshops, Kundenportale, Buchungssysteme, Intranet-Zugänge, webbasierte Verwaltungsoberflächen oder Outlook Web Access. Wenn ja, ist eine WAF dringend empfohlen. Wenn die IT-Umgebung rein intern arbeitet und keine Anwendung extern erreichbar ist, besteht kein unmittelbarer Bedarf.

2. Biete ich APIs an oder konsumiere ich externe APIs?

APIs sind 2026 die mit Abstand am stärksten wachsende Angriffsfläche. Laut Wallarm waren 2025 bereits 17 Prozent aller veröffentlichten Schwachstellen API-bezogen, und 97 Prozent davon lassen sich mit einer einzigen Anfrage ausnutzen. Wer APIs extern bereitstellt, sollte diese absichern.

3. Verarbeiten meine Webanwendungen personenbezogene oder geschäftskritische Daten?

Patientendaten, Zahlungsinformationen, Mandantendaten, Personaldaten. Je sensibler die Daten, desto wichtiger der Schutz auf Anwendungsebene. Ab einer gewissen Datenkritikalität ist eine WAF nicht nur sinnvoll, sondern aus Compliance-Sicht faktisch notwendig.

4. Habe ich die Webanwendung selbst entwickelt oder angepasst?

Eigenentwicklungen und stark angepasste Systeme enthalten erfahrungsgemäß mehr Schwachstellen als gepflegte Standardsoftware. Gerade bei Individualsoftware schließt eine WAF Lücken, die im Code noch nicht behoben wurden. Das ist ein wichtiger Übergangsschutz bis zum nächsten Patch.

5. Unterliege ich regulatorischen Anforderungen?

PCI DSS verlangt explizit den Einsatz einer WAF oder regelmäßige Code-Reviews. Die DSGVO fordert „geeignete technische und organisatorische Maßnahmen", und bei extern erreichbaren Webanwendungen gehört eine WAF praktisch zum Stand der Technik. Mit dem seit Dezember 2025 geltenden NIS-2-Umsetzungsgesetz verschärfen sich die Pflichten für rund 29.500 Unternehmen in Deutschland zusätzlich.

Wann die Antwort „Ja" lautet

Wenn mindestens zwei dieser fünf Fragen mit „Ja" beantwortet werden, ist eine WAF keine optionale Ergänzung mehr, sondern ein notwendiger Baustein der Sicherheitsarchitektur.

OWASP Top 10:2025 – was sich geändert hat und warum das für WAFs relevant ist

Die OWASP Top 10 sind der international anerkannte Maßstab für die kritischsten Sicherheitsrisiken in Webanwendungen. Die im Dezember 2025 veröffentlichte Ausgabe bringt deutliche Verschiebungen gegenüber 2021 und damit auch veränderte Anforderungen an WAF-Konfigurationen.

Für die WAF-Praxis sind drei Entwicklungen besonders relevant.

Security Misconfiguration auf Platz 2

Fehlkonfigurationen wie zu offene Berechtigungen, Default-Zugangsdaten oder unnötig exponierte Dienste sind zur zweitgrößten Bedrohung aufgestiegen. Aus unserer Erfahrung in Firewall-Audits bestätigt sich das. Viele Sicherheitslücken entstehen nicht durch fehlende Technologie, sondern durch unsaubere Konfiguration. Eine WAF kann Fehlkonfigurationen auf Anwendungsebene abfangen, etwa wenn ein Webserver Debug-Informationen oder Stack Traces an den Client sendet.

Supply-Chain-Angriffe erstmals gelistet

Die neue Kategorie A03 adressiert kompromittierte Bibliotheken, manipulierte Build-Prozesse und bösartige Pakete. Eine WAF schützt hier nicht direkt, aber sie kann als letzte Verteidigungslinie abnormales Verhalten erkennen, das von kompromittierten Komponenten ausgeht.

Injection-Angriffe nach wie vor kritisch

Auch wenn Injection von Platz 3 auf 5 gefallen ist, bleibt es die Kategorie mit den meisten zugehörigen CVEs. SQL-Injection und XSS sind nach wie vor der Hauptgrund, warum Unternehmen eine WAF einsetzen. Und das ist nach wie vor berechtigt.

Warum API-Sicherheit 2026 das dominierende Thema ist

In der klassischen WAF-Diskussion geht es um den Schutz von Webseiten und Portalen. 2026 verschiebt sich der Schwerpunkt jedoch massiv in Richtung API-Sicherheit, und dafür gibt es handfeste Gründe.

Die Zahlen sind eindeutig. Laut Wallarm API ThreatStats Report 2026 waren im Jahr 2025 insgesamt 11.053 der 67.058 veröffentlichten Sicherheitsbulletins API-bezogen, also 17 Prozent aller gemeldeten Schwachstellen. Noch gravierender ist die Lage bei aktiv ausgenutzten Schwachstellen. Von den neu in die CISA-KEV-Liste aufgenommenen Einträgen betrafen 43 Prozent APIs. Akamai berichtet, dass sich die durchschnittliche Anzahl täglicher API-Angriffe pro Unternehmen 2025 auf 258 mehr als verdoppelt hat, ein Plus von 113 Prozent gegenüber dem Vorjahr.

Was das für den WAF-Bedarf bedeutet

Wer APIs extern bereitstellt, sei es für Mobile Apps, Partner-Integrationen oder eigene Microservice-Architekturen, braucht 2026 einen Schutzmechanismus auf Anwendungsebene. Moderne WAFs und Web Application and API Protection (WAAP)-Lösungen adressieren genau diese Anforderung, indem sie neben klassischem Webtraffic auch REST-, GraphQL- und SOAP-Anfragen analysieren und schützen.

Was in der Praxis oft übersehen wird, ist die fehlende Übersicht. Viele Unternehmen wissen gar nicht, wie viele APIs sie tatsächlich exponieren. Laut Branchenberichten fehlt mehr als 40 Prozent der Organisationen die vollständige Sicht auf ihre API-Angriffsfläche. Sogenannte „Shadow-APIs", also undokumentierte Endpunkte, die ohne Sicherheitsprüfung in Betrieb gegangen sind, stellen ein erhebliches Risiko dar.

KI-generierter Code und Vibe Coding als neues WAF-Thema

Ein Trend, den wir in Beratungsgesprächen 2026 zunehmend ansprechen müssen, ist der Einsatz von KI-generierten Webanwendungen. Unter dem Stichwort „Vibe Coding" erstellen immer mehr Teams, Freelancer und auch Fachabteilungen Webanwendungen mithilfe von KI-Codegeneratoren wie GitHub Copilot, Cursor oder ChatGPT. Was dabei entsteht, funktioniert häufig schnell und sieht gut aus, wurde aber in vielen Fällen nie einem Security-Review unterzogen.

Schutz vor Angriffen nur teilweise möglich

Das Problem liegt auf der Hand. KI-generierter Code kann unsichere Coding-Praktiken übernehmen oder neu erzeugen. Unzureichende Input-Validierung, fehlende Prepared Statements bei Datenbankabfragen oder hart kodierte Credentials sind mögliche Beispiele. Wenn solche Anwendungen ohne weitere Prüfung ins Internet gestellt werden, entstehen Schwachstellen, bei denen eine WAF teilweise helfen kann. Sie kann typische Angriffsmuster wie SQL Injection, Cross-Site Scripting oder bestimmte Manipulationsversuche erkennen und blockieren. Vollständig absichern kann sie solche Anwendungen jedoch nicht.

Für Unternehmen: Interne Richtlinien für Vibe Coding empfohlen

Für Unternehmen ergibt sich daraus eine doppelte Anforderung. Einerseits sollten interne Richtlinien für den Einsatz von KI-generierten Anwendungen gelten, inklusive Code-Reviews und Sicherheitstests. Andererseits wird die WAF als zusätzliche Schutzschicht wichtiger, je mehr Anwendungen schnell und ohne tiefgreifende Security-Expertise entstehen. Gerade bei kleineren Unternehmen, die keine eigene AppSec-Abteilung haben, kann eine gut konfigurierte WAF das Risiko deutlich reduzieren. Sie ersetzt aber keine sichere Entwicklung, keine saubere Rechteprüfung und keine Prüfung der Anwendungslogik.

Cloud-WAF, Appliance oder integriert? Lösungsansätze im Vergleich

Bei der Auswahl einer WAF stehen drei Ansätze zur Verfügung. Jeder hat seine Berechtigung, und die Wahl hängt von der eigenen Infrastruktur, den Anforderungen und dem verfügbaren Budget ab.

Der Cloud-WAF-Markt wächst stark. Über 50 Prozent aller WAF-Deployments sind bereits cloudbasiert, und Anbieter wie Cloudflare, Akamai oder AWS WAF dominieren dieses Segment. Für viele deutsche KMU ist der Cloud-Ansatz allerdings nicht immer die erste Wahl. Bedenken zur Datenhoheit, vertragliche Anforderungen und die Frage, ob der gesamte Webtraffic über einen US-amerikanischen Cloud-Anbieter geleitet werden soll, spielen gerade im DACH-Raum eine Rolle.

Welcher Ansatz passt zu welchem Unternehmen

Für Unternehmen, die bereits eine Sophos XGS Firewall betreiben und ein bis drei Webanwendungen schützen müssen, ist die integrierte WAF oft der pragmatischste Einstieg. Wenn die Anforderungen wachsen, also mehr Anwendungen, höherer Traffic oder zusätzliche Standorte hinzukommen, lässt sich die Sophos WAF-Funktion auch über virtuelle Software-Firewalls skalieren, etwa in VM- oder Cloud-Umgebungen. Dort kann eine dedizierte virtuelle Firewall ausschließlich für den WAF-Schutz konfiguriert werden, ohne die bestehende Perimeter-Firewall zu belasten. Erst bei wirklich globaler Erreichbarkeit oder Bedarf an spezialisierten Features wie Bot-Management und erweiterte API-Analyse ist der Schritt zu einer dedizierten Cloud-WAF-Plattform sinnvoll.

WAF in der Sophos Firewall: Funktionen, Grenzen und Praxiserfahrung

Bei Sophos XGS Firewalls ist die WAF-Funktionalität im Zusatzmodul Web Server Protection enthalten. Das Modul erweitert die Firewall um einen Reverse Proxy mit Schutzfunktionen auf Anwendungsebene und ist sowohl für Hardware-Appliances als auch für virtuelle Firewalls verfügbar.

Was die Sophos WAF bietet

Die Firewall arbeitet als Reverse Proxy und prüft eingehenden HTTP/HTTPS-Traffic vor der Weiterleitung an den Webserver. Zum Funktionsumfang gehören SQL-Injection- und XSS-Erkennung, Cookie-Signierung, URL- und Form-Hardening, Antivirus-Scanning von Uploads und SSL/TLS-Offloading. Sophos liefert vorkonfigurierte Regelwerke für gängige Szenarien mit, etwa für Microsoft Exchange oder Remote Desktop Gateway. Allerdings ist hier Vorsicht geboten, denn einige dieser Profile stammen noch aus einer Zeit, in der Lync und Skype for Business relevant waren, und die Exchange-Unterstützung endet offiziell bei Version 2013. Für aktuelle Anwendungen ist deshalb eine individuelle WAF-Konfiguration notwendig. Diese erfolgt über WAF-Regeln innerhalb der Firewall-Regeln und lässt sich zentral über Sophos Central verwalten.

Wo die Grenzen liegen

Die Sophos WAF ist eine solide integrierte Lösung, aber kein Ersatz für dedizierte WAF-Plattformen. In der Praxis sehen wir folgende Einschränkungen. Die Unterstützung für Microsoft Exchange endet bei Version 2013, neuere Exchange-Versionen werden offiziell nicht unterstützt. Bot-Management und erweiterte API-Sicherheitsfunktionen, wie sie Cloud-WAFs bieten, fehlen. Bei hohem Traffic kann die WAF-Funktionalität die Firewall-Performance spürbar belasten, insbesondere bei Deep Packet Inspection in Kombination mit SSL-Offloading. Und die Anpassung von WAF-Regeln erfordert Erfahrung, denn False Positives sind bei zu restriktiven Einstellungen ein häufiges Problem.

Für wen die Sophos WAF passt

Für KMU mit ein bis drei extern erreichbaren Webanwendungen, die bereits eine Sophos Firewall einsetzen, ist das Modul ein guter Einstieg. Es spart ein separates Produkt, lässt sich über die bekannte Oberfläche verwalten und deckt die wichtigsten Schutzfunktionen ab. Die Web Server Protection ist Bestandteil des Xstream Protection Bundles und kann auch als Einzelsubscription lizenziert werden.

Aus der Praxis

In einem typischen Projekt haben wir für ein mittelständisches Unternehmen mit Webshop und Kundenportal die Sophos WAF eingerichtet. Der häufigste Aufwand in solchen Projekten ist das Feintuning, also das Unterscheiden zwischen echten Angriffen und Fehlalarmen anhand der WAF-Logs. Nach dieser Phase läuft die WAF im aktiven Blocking-Modus.

Die häufigsten Fehler bei WAF-Projekten

Aus unserer Erfahrung in der Projektarbeit und im Audit-Bereich sehen wir wiederkehrende Fehler, die den Nutzen einer WAF erheblich einschränken.

WAF im „Monitor-only"-Modus belassen

Nach der initialen Einrichtung wird die WAF häufig nur im Logging-Modus betrieben. Angriffe werden zwar erkannt, aber nicht blockiert. Das ist für eine Einführungsphase sinnvoll, sollte aber zeitnah in den aktiven Blocking-Modus überführt werden. In der Praxis bleiben erstaunlich viele WAFs dauerhaft im passiven Modus, und damit wirkungslos.

Zu generische Regelsätze

Viele Unternehmen aktivieren den Standard-Regelsatz und lassen es dabei. Eine WAF muss aber auf die spezifische Anwendung zugeschnitten werden. Welche Parameter erwartet die Anwendung? Welche Anfragen sind legitim? Wo liegen die tatsächlichen Angriffsflächen? Ohne dieses Tuning entstehen entweder False Positives, bei denen legitime Anfragen blockiert werden, oder False Negatives, bei denen Angriffe durchgelassen werden.

Kein Monitoring der WAF-Logs

Eine WAF erzeugt wertvolle Telemetriedaten. Wenn diese nicht ausgewertet werden, idealerweise in einer SIEM-Umgebung oder über XDR und MDR, bleibt die WAF ein Sicherheitsbaustein ohne Lerneffekt.

WAF als alleinige Maßnahme

Eine WAF ist ein Sicherheitsnetz, kein Ersatz für sichere Softwareentwicklung. Webanwendungen müssen im Code sicher entwickelt werden, mit Input Validation, Prepared Statements und sauberer Fehlerbehandlung. Die WAF fängt auf, was trotzdem durchrutscht, aber sie kompensiert nicht grundlegend unsichere Architekturentscheidungen. Das gilt umso mehr, je mehr Anwendungen durch KI-Codegeneratoren ohne tiefgreifendes Security-Wissen entstehen.

WAF und Compliance: DSGVO, PCI DSS, NIS-2

In Beratungsgesprächen ist Compliance mittlerweile einer der häufigsten Gründe für WAF-Projekte. Nicht nur wegen des technischen Nutzens, sondern wegen konkreter regulatorischer Anforderungen.

PCI DSS

Der Payment Card Industry Data Security Standard fordert in Requirement 6.4 explizit den Einsatz einer WAF für alle öffentlich zugänglichen Webanwendungen, die Kreditkartendaten verarbeiten. Die Alternative wären regelmäßige Code-Reviews durch spezialisierte Sicherheitsberater, was in der Praxis deutlich teurer ist als eine WAF.

DSGVO

Die DSGVO verlangt „geeignete technische und organisatorische Maßnahmen" zum Schutz personenbezogener Daten (Art. 32). Bei extern erreichbaren Webanwendungen, die personenbezogene Daten verarbeiten, gehört eine WAF nach aktuellem Stand der Technik zu diesen Maßnahmen. Die durchschnittlichen Kosten eines Datenlecks in Deutschland liegen laut IBM bei 3,87 Millionen Euro. Eine Investition in WAF-Schutz relativiert sich damit schnell.

NIS-2

Das seit dem 6. Dezember 2025 geltende NIS-2-Umsetzungsgesetz betrifft rund 29.500 Unternehmen in Deutschland und verschärft die Anforderungen an IT-Sicherheitsmaßnahmen erheblich. Unternehmen in den betroffenen Sektoren müssen nachweisen, dass sie angemessene technische Maßnahmen umsetzen. WAF-Schutz für extern erreichbare Anwendungen gehört hier zum erwartbaren Maßnahmenspektrum.

Für Branchen wie das Gesundheitswesen, Finanzdienstleister und die Versorgungswirtschaft ist die Kombination aus Regulatorik und Bedrohungslage besonders relevant. Wer in diesen Bereichen Webanwendungen ohne WAF-Schutz betreibt, geht ein messbares rechtliches und finanzielles Risiko ein.

Was Entscheider jetzt tun sollten

Basierend auf der aktuellen Bedrohungslage, den OWASP-2025-Ergebnissen und unserer Projekterfahrung empfehlen wir folgendes Vorgehen.

Anwendungsinventar erstellen

Welche Webanwendungen und APIs sind extern erreichbar? Welche Daten verarbeiten sie? In vielen Unternehmen fehlt diese Übersicht. Ohne sie lässt sich keine fundierte Entscheidung über den WAF-Bedarf treffen.

Vorhandene Schutzmaßnahmen prüfen

Wer bereits eine Sophos Firewall einsetzt, sollte prüfen, ob die Web Server Protection aktiviert und korrekt konfiguriert ist. Häufig ist das Modul lizenziert, aber nicht im Einsatz.

WAF-Regeln nicht „fire and forget" betreiben

Regelmäßiges Tuning, Log-Auswertung und Anpassung an veränderte Anwendungen sind Pflicht. Wer das intern nicht leisten kann, sollte über Managed Security Services oder einen Firewall-Audit nachdenken.

API-Angriffsfläche bewerten

Gerade die API-Sicherheit wird von vielen Unternehmen unterschätzt. Eine externe Schwachstellenanalyse identifiziert exponierte APIs und zeigt konkreten Handlungsbedarf.

Compliance-Anforderungen klären

NIS-2, PCI DSS und branchenspezifische Vorgaben sind komplex. Ein Compliance Assessment zeigt, welche Maßnahmen verpflichtend oder empfohlen sind.

Fazit: WAF häufig eher Pflicht als empfehlenswert

Die Bedrohungslandschaft für Webanwendungen hat sich 2025/2026 deutlich verschärft. 311 Milliarden Angriffe auf Webanwendungen weltweit, API-Angriffe auf Rekordniveau, neue Risikokategorien in den OWASP Top 10 und verschärfte regulatorische Anforderungen durch NIS-2. Gleichzeitig entstehen durch Trends wie Vibe Coding und KI-generierte Anwendungen immer mehr Webanwendungen, die ohne tiefgreifendes Security-Wissen ins Netz gestellt werden. Für Unternehmen, die Webanwendungen oder APIs extern bereitstellen, ist eine Web Application Firewall keine optionale Ergänzung mehr. Sie gehört zum Standardschutz wie die Netzwerk-Firewall selbst.

Der Einstieg muss nicht komplex sein. Wer bereits eine Sophos XGS Firewall einsetzt, kann mit der integrierten Web Server Protection einen soliden Grundschutz aufbauen. Für wachsende Umgebungen bieten virtuelle Sophos Firewalls eine skalierbare Zwischenstufe, und für globale Anforderungen stehen Cloud-WAF- und WAAP-Plattformen zur Verfügung.

Entscheidend ist am Ende nicht die WAF allein, sondern ihre korrekte Konfiguration, regelmäßiges Tuning und die Einbindung in eine ganzheitliche Sicherheitsstrategie aus Firewall, Endpoint Security, MDR und zentralem Management.

Sie möchten wissen, ob Ihre Webanwendungen ausreichend geschützt sind? Unsere Security-Berater prüfen Ihre Umgebung und empfehlen die passende WAF-Strategie. Sprechen Sie uns an.