WAF-False-Positives zähmen: OWASP-Regeln tunen, ohne die App zu brechen

Die WAF, die abgeschaltet wird, schützt niemanden

Es gibt einen sicheren Weg, eine Web Application Firewall wirkungslos zu machen: Sie so scharf stellen, dass sie den ersten legitimen Kunden blockt. Nach dem zweiten Support-Ticket schaltet irgendwer sie „vorübergehend“ in den Nur-Log-Modus, und dort bleibt sie für immer. Der häufigste Grund für eine ungeschützte Anwendung ist nicht eine fehlende WAF — es ist eine, die wegen zu vieler False Positives niemand mehr scharf zu schalten traut.

False-Positive-Tuning ist deshalb keine kosmetische Nacharbeit, sondern die Voraussetzung dafür, dass Schutz überhaupt aktiv bleibt. Und es hat eine bestimmte Reihenfolge.

Warum das OWASP-Regelwerk anfangs zu laut ist

Das OWASP Core Rule Set ist bewusst breit. Es soll Angriffe fangen, die sein Autor nie gesehen hat, und irrt deshalb im Zweifel Richtung Vorsicht. Das ist die richtige Voreinstellung für einen generischen Schutz — aber Ihre Anwendung ist nicht generisch. Ein Rich-Text-Editor, der HTML in einem Feld erlaubt, sieht für eine XSS-Regel aus wie ein Angriff. Eine Such-Query mit SQL-artiger Syntax triggert eine Injection-Regel. Ein Base64-Blob in einem legitimen API-Aufruf wirkt wie eine getarnte Payload. Keine dieser Anfragen ist bösartig — aber die Regel weiß das nicht, weil sie Ihre Anwendung nicht kennt.

Tuning heißt: der Regel diesen Kontext beibringen, ohne den Schutz auszuhöhlen.

Anomalie-Scoring statt Alles-oder-nichts

Der erste Hebel ist, dass eine einzelne verdächtige Regel nicht sofort blockt. Das OWASP-Regelwerk arbeitet mit Anomalie-Scoring: Jede zutreffende Regel addiert Punkte, und erst ab einer Schwelle wird die Anfrage abgewiesen. Ein harmloser Treffer allein reicht nicht — es braucht die Summe mehrerer Signale. Das verschiebt die Frage von „hat irgendeine Regel angeschlagen?“ zu „ist das Gesamtbild dieser Anfrage bösartig?“, und genau dort liegen die meisten False Positives.

Die Schwelle lässt sich pro Route justieren: ein öffentliches Kontaktformular strenger, ein komplexer Editor-Endpunkt toleranter. So tunt man dort, wo der falsche Alarm entsteht, statt eine Regel global zu opfern.

Erst beobachten, dann blocken

Der zweite Hebel ist die Reihenfolge des Ausrollens. Eine neue oder verschärfte Regel läuft erst im Beobachtungsmodus: Sie protokolliert, was sie blockieren würde, ohne es zu tun. In diesem Fenster sieht man im Audit-Log, welche legitimen Anfragen die Regel getroffen hätte — den Editor, die Suche, den API-Client — und stellt gezielt Ausnahmen ein, bevor irgendein echter Nutzer eine Fehlerseite sieht. Erst wenn der Beobachtungslauf sauber ist, geht die Regel in den Blockmodus.

Dasselbe Prinzip trägt das ML-Entity-Scoring, das jede Quelle durch detection → verify → enforce führt: Ein neues Signal darf erst blocken, wenn es sich bewiesen hat. Kein nervöses Modell sperrt einen legitimen Partner aus, nur weil sein Verkehr ungewohnt aussah.

Der Audit-Log ist das Tuning-Werkzeug

Man kann nicht tunen, was man nicht sieht. Jede Entscheidung — geblockt, beobachtet, durchgelassen — landet in einem unveränderlichen, nur-anfügenden Audit-Log, mit Regel-ID, Score und Route. Das ist zugleich der Beleg gegenüber der Revision und das eigentliche Werkzeug: Wer verstehen will, warum ein Kunde am Dienstag nicht bezahlen konnte, findet die Antwort hier — und stellt die Ausnahme, statt zu raten. Die Verarbeitung bleibt auf EU-Edge-Nodes, DSGVO-konform als Architekturvorgabe.

Ehrlich über die Grenzen

Tuning ist ein Gleichgewicht, keine Lösung mit Häkchen. Jede Ausnahme, die Sie einstellen, ist eine kleine bewusst offen gelassene Tür — zu viele davon, und die WAF schützt nichts mehr. Das Ziel ist nicht null False Positives um jeden Preis, sondern die engstmögliche Konfiguration, die Ihre echte Anwendung durchlässt. Diese Balance ist Arbeit, und wir behaupten nicht, sie wegzuautomatisieren — wir geben Ihnen die Werkzeuge (Scoring, Beobachtungsmodus, Audit-Log), sie sauber zu finden. Die Filterung selbst bleibt im Design-Budget von ≤5 ms; siehe die Latenz-Methodik.

Wenn Ihre WAF gerade mehr Kunden als Angreifer blockt, nennen Sie uns Ihre Domain — oder sehen Sie, wie es funktioniert.