TL;DR
Eine WAF an der Edge prüft HTTP- und HTTPS-Anfragen, bevor sie Backends erreichen. Sie eignet sich für protokoll- und anfragespezifische Muster wie Injection, unerlaubte Methoden oder auffällige Request-Strukturen. Fachlicher Kontext, Geschäftslogik und komplexe Autorisierung bleiben jedoch Aufgabe der Anwendung. Entscheidend ist ein Betriebsmodell, das Schutzwirkung und Fehlalarmrisiko kontrolliert.
Einleitung
Eine WAF ist kein Ersatz für Anwendungssicherheit. Der typische Architekturfehler besteht darin, sämtliche Sicherheitsentscheidungen in ein zentrales Regelwerk vor dem Backend zu verlagern. Das funktioniert bei klar erkennbaren Angriffsmustern, scheitert aber an fachlichen Zusammenhängen: Ob eine Bestellung zulässig ist, hängt nicht nur von URL und HTTP-Methode ab, sondern von Benutzer, Bestand, Status und Geschäftsprozess. Eine belastbare WAF-Architektur trennt deshalb generische Filterung an der Edge von kontextabhängiger Validierung in der Anwendung. Die ayedo Edge Cloud bildet den öffentlichen Eingang vor HTTP-/HTTPS-Services und kann Requests dort per Web Application Firewall prüfen, bevor sie an die Backends verteilt werden.
1. Welche Anfragen eine WAF sinnvoll an der Edge prüft
Eine WAF ist besonders wirksam, wenn sich ein Angriff aus Eigenschaften des Requests ableiten lässt. Dazu gehören verdächtige Payloads in Query-Parametern, Pfaden, Formularfeldern oder HTTP-Headern, typische Muster für SQL Injection und Cross-Site Scripting sowie unzulässige HTTP-Methoden. Auch Größenlimits, auffällige Content-Typen, ungewöhnliche Request-Strukturen oder bekannte Signaturen lassen sich zentral bewerten.
Der Vorteil der Edge-Position liegt im Zeitpunkt der Prüfung: Schädlicher Traffic wird vor der Anwendung verworfen und belastet weder Backend-Prozesse noch nachgelagerte Sicherheitskomponenten. Das ist insbesondere bei öffentlich erreichbaren APIs und Webanwendungen relevant. Die WAF wird dabei nicht zur einzigen Schutzschicht. TLS kann an der Edge terminiert werden, während das Backend verborgen bleibt und nur den von der Edge weitergeleiteten Traffic verarbeitet. Die Filterung reduziert damit die Angriffsfläche, ersetzt aber weder sichere Implementierung noch Patch- und Berechtigungsmanagement.
2. WAF-Regeln zwischen Standard und Anwendungskontext
Regelwerke lassen sich grob in generische und anwendungsspezifische Regeln unterteilen. Generische Regeln erkennen bekannte Angriffsklassen unabhängig von der konkreten Fachanwendung. Anwendungsspezifische Regeln berücksichtigen dagegen definierte Pfade, erlaubte Methoden, Parameterformate oder erwartete Content-Typen einer API. Je genauer eine Regel den legitimen Datenverkehr beschreibt, desto höher kann ihre Schutzwirkung sein – gleichzeitig steigt der Pflegeaufwand.
Eine WAF sollte nicht jede ungewöhnliche Eingabe blockieren. Viele valide Anwendungen akzeptieren Sonderzeichen, große JSON-Dokumente oder dynamische Parameter. Zu restriktive Regeln erzeugen Fehlalarme und können reguläre Geschäftsprozesse unterbrechen. Deshalb müssen Regeln beobachtbar eingeführt, anhand realer Requests bewertet und mit klarer Zuständigkeit betrieben werden. Die technische Entscheidung lautet nicht nur „blockieren oder erlauben“, sondern auch, welche Regel in welchem Modus gilt, wer Ausnahmen verantwortet und wie Änderungen nachvollziehbar bleiben.
3. Betriebsmodelle und Umgang mit Fehlalarmen
In der Praxis haben sich drei Betriebsmodi etabliert: Überwachung, gezielte Blockierung und umfassende Durchsetzung. Im Überwachungsmodus protokolliert die WAF Treffer, ohne Requests abzulehnen. Das eignet sich für die Einführungsphase und für neue Regelgruppen. Gezielte Blockierung beschränkt sich auf belastbare Regeln oder besonders kritische Endpunkte. Eine umfassende Durchsetzung setzt voraus, dass Anwendung, Datenformate und Ausnahmefälle ausreichend bekannt sind.
Entscheidend ist ein definierter Feedbackprozess zwischen Plattform-, Security- und Anwendungsteams. Ein Fehlalarm ist nicht nur ein technisches Problem: Er kann Umsatzprozesse, Integrationen oder interne APIs unterbrechen. Umgekehrt darf eine hohe Zahl beobachteter Treffer nicht automatisch als Sicherheitsvorfall interpretiert werden. Benötigt werden Kontext, Priorisierung und eine Entscheidung, ob eine Ausnahme die WAF-Regel präzisiert oder ein Fehler in der Anwendung vorliegt. Traffic- und Usage-Statistiken an der Edge können dabei die Bewertung des Datenverkehrs unterstützen, ersetzen aber keine fachliche Analyse.
4. Wo Edge-Filterung endet und Anwendungsschutz beginnt
Eine WAF kann erkennen, dass ein Request formal verdächtig ist. Sie kann jedoch meist nicht zuverlässig beurteilen, ob ein authentifizierter Benutzer eine bestimmte Ressource verändern darf oder ob ein Geschäftsprozess in der richtigen Reihenfolge abläuft. Diese Entscheidungen gehören in die Anwendung oder in dafür vorgesehene Autorisierungsdienste. Gleiches gilt für Plausibilitätsprüfungen, Transaktionskonsistenz, Mandantentrennung und Missbrauchslogik mit Domänenwissen.
Die Trennung der Verantwortlichkeiten verbessert auch die Architektur. Die Edge übernimmt den öffentlichen Traffic-Eingang, TLS-nahe Verarbeitung, WAF-Prüfung und Verteilung; das Backend validiert Identität, Berechtigungen und fachliche Semantik. Durch Backend Cloaking muss die Anwendung nicht direkt öffentlich adressierbar sein. Bei mehreren Backends oder Ausfallpfaden bleiben Health Checks und Failover Aufgaben der Edge-Infrastruktur, während die Anwendung weiterhin für die Korrektheit ihrer Entscheidungen verantwortlich bleibt. Eine WAF-Architektur ist damit eine zusätzliche Kontrollschicht, kein zentraler Ersatz für Secure Coding.
Praxis- und Betriebsszenario
Eine öffentliche API akzeptiert JSON-Anfragen für Kontoänderungen. An der ayedo Edge Cloud werden zunächst nur HTTPS-Requests auf den vorgesehenen API-Pfaden angenommen. Die WAF prüft Methode, Content-Typ, Request-Größe und bekannte Angriffsmuster. Neue Regeln laufen zunächst im Überwachungsmodus. Nach der Auswertung werden eindeutig unzulässige Methoden blockiert, während fachliche Prüfungen – etwa ob das Konto dem authentifizierten Mandanten gehört – im Backend verbleiben.
Würde diese Mandantenprüfung an die Edge verlagert, müsste das Regelwerk fachliche Daten und Anwendungszustände kennen. Jede Änderung am Geschäftsmodell würde dann auch die zentrale Filterlogik beeinflussen. Die Edge bleibt deshalb stabil auf Protokoll- und Request-Ebene, während die Anwendung ihre Domänenlogik unabhängig weiterentwickelt.
FAQ
Kann eine WAF alle API-Angriffe verhindern?
Nein. Sie erkennt viele protokoll- und payloadbezogene Angriffsmuster. Autorisierung, Geschäftslogik, Missbrauchserkennung und sichere Implementierung müssen weiterhin in der Anwendung umgesetzt werden.
Sollte jede WAF-Regel sofort blockieren?
Nein. Neue oder komplexe Regeln sollten zunächst beobachtet und anhand legitimer Requests bewertet werden. Blockierung eignet sich für Regeln mit geringer Fehlalarmwahrscheinlichkeit und klarer technischer Grundlage.
Wo wird die WAF in der Architektur platziert?
Vor den öffentlich erreichbaren Backends, typischerweise an der Edge. Dort kann sie Requests prüfen, bevor diese TLS-terminiert, verteilt und an die eigentlichen Anwendungen weitergeleitet werden.
Fazit
Eine tragfähige WAF-Architektur verteilt Sicherheitsaufgaben bewusst: Die Edge filtert erkennbare Angriffs- und Protokollmuster, die Anwendung entscheidet über Identität, Berechtigung und fachliche Zulässigkeit. Für die ayedo Edge Cloud bedeutet das eine klare Rolle als öffentlicher Eingang mit WAF-Prüfung vor den Backends – nicht als Ersatz für Anwendungsschutz. Entscheidend sind kontrollierte Regeländerungen, nachvollziehbare Ausnahmen und ein Betriebsmodell, das Fehlalarme ebenso ernst nimmt wie echte Angriffe.