Content Security Policy: meta http-equiv

Content Security Policy ist eine vom Browser erzwungene Richtlinie, die einschränkt, welche Ressourcen eine Seite laden und ausführen darf. Sie ist der stärkste Schutz gegen Cross-Site-Scripting: Selbst wenn ein Angreifer ein <script>-Tag einschleust, führt der Browser es nicht aus, sofern die Richtlinie dies nicht erlaubt.

CSP kann als HTTP-Response-Header (Content-Security-Policy: ...) oder als Meta-Tag in HTML gesendet werden: <meta http-equiv="Content-Security-Policy" content="...">. Der Header wird bevorzugt; das Meta-Tag ist nützlich, wenn Sie den Server nicht kontrollieren können.

default-src dient als Fallback für nicht spezifizierte Ressourcentypen. script-src, style-src, img-src, connect-src (XHR/fetch), font-src und frame-src schränken jeweils ihren Ressourcentyp ein. Setzen Sie bestimmte Origins auf eine Allowlist oder verwenden Sie 'self', um nur dieselbe Origin zu erlauben.

'self' (in Anführungszeichen) bezeichnet die eigene Origin der Seite. script-src 'self' bedeutet: „Führe nur Skripte aus, die auf derselben Origin wie die Seite gehostet werden.“ Dies ist die Grundlage der meisten Richtlinien; fügen Sie bei Bedarf bestimmte externe CDNs hinzu.

Standardmäßig blockiert CSP alle Inline-<script>-Tags und Event-Handler-Attribute (onclick). Dies ist der stärkste XSS-Schutz: Ein eingeschleustes <script> kann nicht ausgeführt werden, weil es inline ist. Verschieben Sie alle Skripte in externe Dateien, die über src eingebunden werden.

Verwenden Sie für notwendige Inline-Skripte eine Nonce: Der Server generiert pro Anfrage ein zufälliges Token, setzt es in CSP als script-src 'nonce-RANDOM' und fügt nonce="RANDOM" zu legitimen <script>-Tags hinzu. Eingeschleusten Skripten fehlt die Nonce, daher werden sie blockiert.

'unsafe-inline' erlaubt Inline-Skripte und -Styles wieder. 'unsafe-eval' erlaubt eval() und new Function() wieder. Beides schwächt CSP erheblich – verwenden Sie diese Optionen während einer Migration nur als letzten Ausweg und planen Sie, sie zu entfernen.

Über ein Meta-Tag bereitgestelltes CSP kann die Direktive report-uri (und andere Reporting-Funktionen) nicht verwenden. Außerdem wird die Richtlinie später wirksam als bei einem Header – alles vor dem Meta-Tag ist ungeschützt. Header sind eindeutig besser; verwenden Sie Meta-Tags nur als Fallback.

Testen Sie eine neue Richtlinie, ohne die Website zu beeinträchtigen: Content-Security-Policy-Report-Only: .... Der Browser meldet Verstöße, ohne sie zu blockieren. So können Sie die Richtlinie verfeinern, bis sie alle legitimen Ressourcen erlaubt, bevor Sie zur Durchsetzung wechseln.

Wenn Sie style-src 'unsafe-inline' vergessen, werden Inline-Styles blockiert (die häufig von Frameworks erzeugt werden). Wenn Sie connect-src vergessen, werden AJAX-Anfragen an APIs blockiert. Testen Sie die Richtlinie immer zuerst im Report-Only-Modus und prüfen Sie die Konsole auf blockierte Ressourcen.

Eine strikte CSP kombiniert script-src 'nonce-RANDOM' 'strict-dynamic' für Skripte mit einer eng gefassten Allowlist für alle anderen Ressourcen. 'strict-dynamic' erlaubt Nonce-Skripten, weitere Skripte zu laden, ohne jedes einzelne aufzulisten – das ist wesentlich einfacher zu verwalten als Allowlists pro Origin.

Wie schützt CSP vor XSS-Angriffen, selbst wenn ein Angreifer erfolgreich ein Script-Tag einschleust?

CSP ist eine vom Browser erzwungene Richtlinie, die festlegt, welche Skripte, Styles, Bilder und anderen Ressourcen geladen werden dürfen. Stellen Sie sie über einen Response-Header (bevorzugt) oder ein Meta-Tag bereit. Verwenden Sie Nonces für benötigte Inline-Skripte, vermeiden Sie unsafe-inline und unsafe-eval und testen Sie zunächst im Report-Only-Modus. Eine strikte CSP mit 'nonce-X' 'strict-dynamic' ist heute die Grundlage.