Content Security Policy (CSP) ist ein Sicherheitsmechanismus des Browsers, mit dem eine Website festlegt, aus welchen Quellen Skripte, Styles, Frames und andere Inhalte geladen werden dürfen, und so Injection-Angriffe eindämmt.
Wie CSP funktioniert
Der Server sendet die Richtlinie im HTTP-Antwortheader Content-Security-Policy. Der Browser lädt oder führt dann nichts aus, was die Richtlinie nicht erlaubt. Wichtige Direktiven:
- default-src und script-src – erlaubte Quellen für Inhalte und JavaScript; Inline-Skripte werden blockiert, sofern sie keine passende Nonce oder keinen passenden Hash tragen;
- ’strict-dynamic‘ – vertraut Skripten, die von bereits vertrauenswürdigen Skripten geladen werden, was Nonce-basierte Richtlinien praxistauglich macht;
- frame-ancestors – welche Websites die Seite in einen Frame einbetten dürfen;
- connect-src und form-action – wohin die Seite Daten senden darf;
- report-to – wohin Verstoßberichte geschickt werden.
Mit dem Header Content-Security-Policy-Report-Only können Entwickler eine Richtlinie testen, ohne etwas zu blockieren. CSP ist vom W3C standardisiert; aktuell ist Level 3.
Warum CSP wichtig ist
CSP ist eine zusätzliche Verteidigungsschicht gegen Cross-Site-Scripting: Selbst wenn ein Angreifer ein Script-Tag einschleust, führt der Browser es nicht aus. Die Direktive frame-ancestors verhindert Clickjacking, und eingeschränkte Verbindungsziele erschweren es Formjacking-Skimmern, gestohlene Kartendaten an Domains der Angreifer zu senden. Eine Richtlinie ist allerdings nur so gut wie ihre Regeln: Wer ‚unsafe-inline‘ oder ganze CDN-Domains erlaubt, macht sie oft trivial umgehbar.
Best Practices
- Strikte Nonce- oder Hash-basierte Richtlinien langen Domain-Allowlists vorziehen.
- Auf ‚unsafe-inline‘ und ‚unsafe-eval‘ verzichten.
- Zunächst im Report-Only-Modus ausrollen und Verstoßberichte auswerten.
- CSP als Ergänzung zu Ausgabe-Kodierung und Eingabevalidierung sehen, nicht als Ersatz.
