Skip to content

WAFs und XSS-Filter: was in Produktion wirklich bricht

Filter können Rauschen reduzieren, normalisieren, blockieren oder verändern Payloads in Produktion aber oft so, dass sich der Test ändert.

Veröffentlicht am 1 Min. Lesezeit

WAFs und Filter sind keine Dekoration. Sie verändern, was die Anwendung erreicht, und damit den XSS-Test.

Manchmal blockieren sie offensichtliche Strings. Manchmal dekodieren sie eine Schicht. Manchmal protokollieren, kürzen oder normalisieren sie Zeichen, bevor das Backend die Eingabe sieht. Wer das ignoriert, zieht falsche Schlüsse.

Blockiert heißt nicht behoben

Wenn ein Filter <script> blockiert, kann der Encoding-Fehler weiterhin bestehen. Die richtige Frage lautet, ob nicht vertrauenswürdige Eingabe in irgendeiner gültigen Form einen gefährlichen Kontext erreichen kann.

Beobachte die Transformation

Vergleiche gesendeten, empfangenen und gerenderten Wert. Wenn du zeigen kannst, wo die Veränderung passiert, wird der Report für Entwicklung und Security nützlicher.

Produktion hat Reibung

Rate Limits, regionale Regeln, Proxies und andere Header können Ergebnisse verändern. Dokumentiere die genaue Testumgebung, bevor du von Bypass oder Mitigation sprichst.

Verwandte Artikel

Verantwortungsvolle XSS-Tests hängen von Scope, sauberer Evidenz, Datenminimierung und dem richtigen Zeitpunkt zum Stoppen ab.
Ein praktischer Blick darauf, warum XSS-Werkzeuge interne URLs, private Fragmente und sensible Testnotizen nicht serverseitig verarbeiten sollten.
Die Payload-Auswahl ist weniger wichtig als der Injektionskontext: HTML, Attribute, URLs, Scripts und DOM-Sinks scheitern unterschiedlich.