Die Content-Security-Policy (CSP) ist ein HTTP-Header, mit dem eine Webseite festlegt, welche Ressourcen sie laden darf. Sie ist die letzte Verteidigungslinie gegen Cross-Site Scripting (XSS): Selbst wenn ein Angreifer Code einschleust, verweigert der Browser die Ausführung, weil die Quelle nicht erlaubt ist.
So funktioniert CSP
Der Server sendet den Header Content-Security-Policy mit einer Liste von Direktiven. Jede Direktive regelt eine Ressourcen-Kategorie:
Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' data:; object-src 'none'default-src— Fallback für alle nicht genannten Kategorien.script-src— erlaubte Quellen für JavaScript;style-srcfür CSS,img-srcfür Bilder.object-src 'none'— verbietet Plugins wie Flash (häufige Angriffsfläche).base-uri 'none'— verhindert Base-Tag-Hijacking.
Moderne Absicherung: Nonces und Hashes
Für Inline-Skripte braucht es statt 'unsafe-inline' bessere Mechanismen: Bei jeder Seitenauslieferung erzeugt der Server einen frischen Nonce (Zufallswert) und setzt ihn in den Header und in das Script-Tag:
script-src 'nonce-1a2b3c'
<script nonce="1a2b3c">...</script>Nur Skripte mit passendem Nonce werden ausgeführt. Mit 'strict-dynamic' vertrauen selbst erlaubte Skripte nachgeladenen Skripten, ohne dass jede Domain einzeln gelistet werden muss.
Häufige Fehler
'unsafe-inline'inscript-src— macht die CSP für XSS weitgehend wirkungslos.- Zu viele erlaubte Quellen (Wildcards wie
https:ohne Einschränkung). - Nur per Meta-Tag statt HTTP-Header: Funktioniert, aber kein Reporting und keine strikte Durchsetzung vor dem Parsing.
CSP ergänzt die Same-Origin-Policy und das SameSite-Attribut: SOP begrenzt den Zugriff zwischen Origins, SameSite schützt Cookies, CSP kontrolliert, welche Ressourcen überhaupt geladen werden.