Warum ein XSS-Payload-Generator clientseitig bleiben sollte

Ein XSS-Generator, der jede Eingabe an ein Backend sendet, verlangt die falsche Art von Vertrauen.

Während einer Prüfung sind Eingaben selten saubere Demo-Daten. Sie können interne Hostnamen, Staging-Pfade, Tenant-IDs, HTML aus einem Admin-Panel, kopierte CSP-Header oder Notizen aus einem noch nicht öffentlichen Bericht enthalten. Diese Daten nur zum Zusammensetzen eines Payloads an einen Server zu schicken, ist unnötig riskant.

Der Browser kann diese Arbeit erledigen.

Logs sind der langweilige Ausfallmodus

Die meisten Leaks sind unspektakulär. Ein Reverse Proxy protokolliert Request-Bodies während eines Debug-Fensters. Observability erfasst eine Exception. Ein CDN speichert genug Metadaten, um den Ablauf zu rekonstruieren.

Für XSS-Werkzeuge entfernt lokale Ausführung eine ganze Risikoklasse. IndexedDB, Exporte und eigene Templates brauchen weiterhin Schutz, aber das Tool wird nicht automatisch zu einem entfernten Sammler von Audit-Daten.

Serverseitige Normalisierung täuscht

Backends verändern Eingaben: sie dekodieren, normalisieren Pfade, lehnen Zeichen ab, ersetzen ungültiges Unicode oder kürzen Logs. Dann debuggt man das Werkzeug statt des Ziels.

submitted: %253Cimg%2520src=x%2520onerror=alert(1)%253E
api saw:   %3Cimg%20src=x%20onerror=alert(1)%3E
target:    <img src=x onerror=alert(1)>

Ein lokales Werkzeug sollte jede Transformation klar zeigen: Rohpayload, Mutation, URL-Encoding, HTML-Entities, Base64 und finales Ergebnis.