Skip to content

CSP behebt kein XSS. Mit Glück begrenzt es den Schaden

Content Security Policy ist nützlich, ersetzt aber kein kontextuelles Encoding, sichere DOM-APIs oder das Entfernen gefährlicher Sinks.

Veröffentlicht am 1 Min. Lesezeit

Content Security Policy ist eine der am häufigsten missverstandenen Web-Sicherheitsmaßnahmen.

Sie ist kein Patch. CSP ist eine Browser-Policy, die einige Ausführungspfade blockieren kann, nachdem die Anwendung bereits unsichere Ausgabe erzeugt hat. Das ist wertvoll, kommt aber spät.

Wenn nicht vertrauenswürdige Eingaben einen ausführbaren Kontext erreichen, hat die Anwendung weiterhin ein XSS-Problem.

Eine strenge Policy verändert die Payload-Klasse

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

Inline Handler wie onerror=alert(1) sollten scheitern. Viele javascript:-URLs und fremde Scripts ebenfalls. Sicher ist die Anwendung dadurch nicht: Tester müssen nach Same-Origin-Gadgets, wiederverwendeten Nonces oder Legacy-Routen mit unsafe-inline fragen.

CSP ist kein Output-Encoding

Die Lösung für reflektierte HTML-Injektion bleibt kontextuelles Encoding. Die Lösung für DOM-XSS bleibt das Entfernen unsicherer Sinks oder passende Sanitization. CSP hilft, wenn etwas durchrutscht, sollte aber nie die primäre Kontrolle sein.

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.