Sicherheits-Ratgeber
Content Security Policy, verständlich erklärt
Die Content Security Policy ist der eine Header, der zu Ihrer eigenen Website passen muss. Dieser Ratgeber behandelt die Direktiven, auf die es ankommt, wie Sie die Richtlinie prüfen, die Ihre Besucher tatsächlich erhalten, wie Sie beheben, was die Prüfung findet, und eine Einführung, die Ihre Seiten nicht zerlegt.
01 Warum sie wichtig ist
Die letzte Verteidigungslinie gegen eingeschleuste Skripte
Der Content-Security-Policy-Header sagt dem Browser, aus welchen Quellen eine Seite Code, Stylesheets, Bilder und andere Ressourcen laden darf. Alles außerhalb dieser Positivliste wird abgelehnt, ganz gleich, wie es auf die Seite gekommen ist. Genau das macht sie zum stärksten Schutz gegen Cross-Site-Scripting: Selbst wenn ein Angreifer ein Script-Tag einschleust, führt der Browser es nicht aus.
Sie ist zugleich der Header, der am ehesten etwas kaputt macht, weil sie Ihre Website beschreibt und keine allgemeine Regel. Eine irgendwo abgeschriebene Richtlinie blockiert entweder Ressourcen, die Sie brauchen, oder erlaubt so viel, dass sie nichts mehr schützt. Der Weg dahin führt über Messen vor Erzwingen, und genau dafür gibt es den Report-Only-Modus.
02 Die Direktiven
Sieben Direktiven, die die Richtlinie tragen
default-src
Was sie bewirkt. Setzt die Rückfall-Quellenliste für jeden Ressourcentyp, der keine eigene Direktive hat. Alles, was Sie vergessen, erbt damit diesen Wert, statt unbeschränkt zu bleiben.
Warum sie wichtig ist. Sie macht aus einer Liste von Ausnahmen eine geschlossene Tür. Ohne sie bleibt jeder Ressourcentyp offen, an den Sie nie gedacht haben.
default-src 'self' script-src
Was sie bewirkt. Listet die Quellen, aus denen der Browser JavaScript ausführen darf. Mit einer Nonce oder einem Hash erlaubt sie genau die Inline-Skripte, die Sie ausliefern, und lehnt jedes andere ab.
Warum sie wichtig ist. Das ist die Direktive, die Cross-Site-Scripting tatsächlich stoppt. Ein unsafe-inline an dieser Stelle gibt den größten Teil des Schutzes wieder auf, weshalb sich der Aufwand für eine Nonce lohnt.
script-src 'self' 'nonce-{RANDOM}' style-src
Was sie bewirkt. Erledigt dieselbe Aufgabe für Stylesheets und Inline-Style-Blöcke, bei strengerer Fassung auch für style-Attribute.
Warum sie wichtig ist. Eingeschleustes CSS kann über Attribut-Selektoren Formularwerte auslesen und Bedienelemente verstecken oder nachbauen. Das Risiko ist kleiner als bei Skripten, aber nicht theoretisch.
style-src 'self' frame-ancestors
Was sie bewirkt. Benennt die Seiten, die Ihre Seiten in einem Frame oder Iframe einbetten dürfen. Mit none darf es niemand.
Warum sie wichtig ist. Die Direktive ersetzt X-Frame-Options und verhindert Clickjacking, bei dem Ihre Website unsichtbar über eine Angreiferseite gelegt wird, damit echte Klicks auf Ihren Schaltflächen landen.
frame-ancestors 'none' object-src
Was sie bewirkt. Steuert die alten Elemente object, embed und applet, die Plugin-Inhalte laden können, welche sich um den Rest Ihrer Richtlinie nicht kümmern.
Warum sie wichtig ist. Kaum eine Website braucht sie noch, deshalb kostet none nichts und schließt einen Umweg, den ältere Browser weiterhin zulassen.
object-src 'none' base-uri
Was sie bewirkt. Beschränkt, was ein base-Element auf der Seite als Basis-URL des Dokuments setzen darf.
Warum sie wichtig ist. Ohne sie kann ein einziges eingeschleustes base-Tag alle relativen Skripte und Links der Seite still auf einen fremden Host umlenken, während script-src korrekt aussieht.
base-uri 'self' form-action
Was sie bewirkt. Benennt die Ziele, an die ein Formular Ihrer Seite senden darf. Formulare haben hier keine eigene Rückfallebene: default-src deckt sie nicht ab, ohne diese Direktive darf ein Formular also überallhin senden.
Warum sie wichtig ist. Ein eingeschleustes Formular oder ein verändertes action-Attribut schickt alles, was ein Besucher eingetippt hat, direkt an einen fremden Host, und die Seite sieht dabei unverändert aus. Fast jede Website sendet ausschließlich an sich selbst, deshalb kostet self nichts.
form-action 'self'03 Prüfen
CSP prüfen
Drei Wege, die Richtlinie zu sehen, die ein Browser tatsächlich erhält, vom schnellen Blick bis zur vollständigen Bewertung. Prüfen Sie immer die ausgelieferte Seite und nicht Ihre Konfigurationsdatei: ein CDN, ein CMS-Plugin oder ein zweiter Server-Block kann den Header auf dem Weg nach draußen ergänzen, ersetzen oder verwerfen.
Im Browser: DevTools
Öffnen Sie die Seite, drücken Sie F12 und wechseln Sie in den Tab Netzwerk. Laden Sie neu, wählen Sie die erste Anfrage vom Typ document und suchen Sie unter Antwort-Header nach content-security-policy und content-security-policy-report-only. Eine im Meta-Tag gesetzte Richtlinie erscheint dort nicht; suchen Sie dafür im Tab Elemente nach http-equiv.
Die Konsole zeigt, was die Richtlinie ablehnt, während die Seite läuft. Jede blockierte Ressource bekommt eine Zeile mit der Direktive, die sie gestoppt hat, und Verstöße gegen eine Report-Only-Richtlinie tragen das Präfix [Report Only]. Eine Konsole ohne solche Zeilen auf den Seiten, auf die es ankommt, auch Login und Kasse, ist das erste Zeichen, dass die Richtlinie zu Ihrer Website passt.
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-4f9GqkTb0yXw'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. [Report Only] Refused to load the script 'https://cdn.example.net/widget.js' because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-4f9GqkTb0yXw'".Auf der Kommandozeile: curl
curl -sI fragt nur die Header ab und gibt sie so aus, wie der Server sie gesendet hat, ohne Browser-Cache, Erweiterungen oder angemeldete Sitzung dazwischen. Die Ausgabe unten stammt von einer Website, die eine Richtlinie erzwingt und gleichzeitig eine strengere im Report-Only-Modus testet, und genau so sind die beiden Header zu kombinieren.
$ curl -sI https://www.example.com/ | grep -i '^content-security-policy' content-security-policy: default-src 'self'; script-src 'self' 'nonce-4f9GqkTb0yXw'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none' content-security-policy-report-only: default-src 'self'; script-src 'self' 'nonce-4f9GqkTb0yXw'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; require-trusted-types-for 'script'curl -I sendet eine HEAD-Anfrage, und manche Server und Anwendungen beantworten HEAD mit anderen Headern als einen normalen Seitenaufruf. Fehlt die Richtlinie hier, obwohl der Browser eine zeigt, wiederholen Sie die Prüfung mit curl -s -o /dev/null -D - und der URL: das ist eine normale GET-Anfrage, von der nur die Header ausgegeben werden. Prüfen Sie die endgültige URL nach jeder Weiterleitung, denn eine Richtlinie an der Weiterleitung schützt nichts.
Mit dem Scanner
Unser kostenloser Scan liest den Header, die Report-Only-Variante und eine Richtlinie im Meta-Tag und bewertet die Richtlinie, statt nur festzustellen, dass es eine gibt: unsafe-inline oder unsafe-eval, Wildcard-Quellen, fehlende frame-ancestors, base-uri oder form-action und ein object-src, das nicht none ist. Jede Schwäche steht namentlich im Befund, Sie wissen also, welchen Teil der Richtlinie Sie ändern müssen.
Eine Richtlinie, die heute besteht, kann der nächste Deploy oder das nächste Plugin-Update wieder aufweichen. Wie Sie das bemerken, beschreiben zwei eigene Ratgeber.
04 Das Ergebnis lesen
Fünf Befunde und wie Sie sie beheben
Das sind die Ergebnisse, die unser Scanner zu einer Content-Security-Policy meldet, mit ihrer Bedeutung für den Schutz und der Änderung, die sie beseitigt. Schwächen einer vorhandenen Richtlinie sind in einem Befund zusammengefasst, Content-Security-Policy ist vorhanden, aber schwach, der jede davon beim Namen nennt.
'unsafe-inline'
Was der Scanner meldet. Content-Security-Policy ist vorhanden, aber schwach, mit unsafe-inline in der Liste.
Was es bedeutet. Die Richtlinie erlaubt jedes Inline-Skript und jeden Style-Block, auch einen eingeschleusten. In script-src gibt das den größten Teil des Schutzes gegen Cross-Site-Scripting auf. Wir werten es nicht, wenn dieselbe Direktive zusätzlich eine Nonce, einen Hash oder strict-dynamic enthält, denn dann ignorieren Browser unsafe-inline.
So beheben Sie es. Geben Sie jedem Inline-Skript eine Nonce, die je Antwort neu erzeugt wird, und entfernen Sie dann unsafe-inline. Inline-Event-Handler wie onclick können keine Nonce tragen, verschieben Sie sie deshalb zuerst in Ihre Skriptdateien.
script-src 'self' 'nonce-{RANDOM}' *, https:, http:
Was der Scanner meldet. Content-Security-Policy ist vorhanden, aber schwach, mit wildcard-source in der Liste.
Was es bedeutet. Eine Quellenliste enthält *, https: oder http:. Dann kommt jeder Host im Internet in Frage, auch einer, den der Angreifer kontrolliert, und die Direktive beschränkt nur noch das Schema.
So beheben Sie es. Ersetzen Sie die Wildcard durch die Origins, von denen Sie tatsächlich laden. Der Netzwerk-Tab oder eine Woche Report-Only-Meldungen liefert Ihnen die Liste.
script-src 'self' https://cdn.example.net form-action, base-uri, frame-ancestors
Was der Scanner meldet. Content-Security-Policy ist vorhanden, aber schwach, mit no-form-action, no-base-uri, no-frame-ancestors oder object-src-not-none in der Liste.
Was es bedeutet. form-action, base-uri und frame-ancestors fallen nicht auf default-src zurück. So streng der Rest der Richtlinie auch ist, ohne sie darf ein Formular überallhin senden, ein eingeschleustes base-Tag jede relative URL umlenken und jede fremde Seite Ihre einbetten. object-src-not-none heißt, dass Plugin-Inhalte weiterhin erlaubt sind.
So beheben Sie es. Nennen Sie sie ausdrücklich. Fast jede Website kann die Werte unten unverändert übernehmen.
object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none' Content-Security-Policy-Report-Only
Was der Scanner meldet. Content-Security-Policy wird nur im Report-Only-Modus ausgeliefert.
Was es bedeutet. Die Richtlinie existiert, blockiert aber nichts. Wir bewerten das als hoch, weil es beim schnellen Hinsehen nach Schutz aussieht, während keiner wirkt.
So beheben Sie es. Sobald die Meldungen nichts mehr enthalten, was Sie für legitim halten, senden Sie denselben Wert unter dem erzwingenden Header-Namen. Den Report-Only-Header behalten Sie nur, um die nächste, strengere Fassung zu testen.
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" always; <meta http-equiv>
Was der Scanner meldet. Content-Security-Policy wird nur über ein Meta-Tag ausgeliefert.
Was es bedeutet. Ein Meta-Tag funktioniert für die meisten Direktiven, aber frame-ancestors, report-uri und sandbox werden dort ignoriert, und alles, was der Browser vor dem Tag verarbeitet hat, ist nicht abgedeckt.
So beheben Sie es. Senden Sie die Richtlinie als Response-Header aus Ihrem Webserver oder CDN und entfernen Sie das Meta-Tag, sobald der Header ausgeliefert wird.
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" always;05 Einführung
Erst Report-Only, dann erzwingend
Senden Sie Content-Security-Policy-Report-Only mit der Richtlinie, die Sie anstreben. Der Browser blockiert nichts, er meldet nur, was er blockiert hätte. So beobachten Sie eine echte Richtlinie gegen echten Verkehr. Sobald die Meldungen verstummen, senden Sie dieselbe Richtlinie im erzwingenden Content-Security-Policy-Header und nehmen den Report-Only-Header heraus.
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; report-uri /csp-report" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'" always;Zwei Punkte dazu. Senden Sie nach dem Umschalten nur noch einen der beiden Header, sonst sammelt die Report-Only-Fassung weiter für eine Richtlinie, die längst aktiv ist. Und erzeugen Sie Nonces je Antwort neu: eine über mehrere Anfragen wiederverwendete Nonce ist nicht besser, als Inline-Skripte gleich zu erlauben.
06 Fragen
Was zur CSP gefragt wird
Kann ich eine Content Security Policy im Meta-Tag setzen?
Ja, und für die meisten Direktiven funktioniert das. frame-ancestors, report-uri und sandbox werden im Meta-Tag jedoch ignoriert. Der Response-Header ist die vollständigere Variante, unser Scanner liest beide.
Muss ich vorher jedes Inline-Skript entfernen?
Nein. Mit einer Nonce behalten Sie die Inline-Skripte, die Sie selbst kontrollieren: Der Server setzt einen Zufallswert in den Header und denselben Wert an jedes Script-Tag, das er ausliefert. Aufgeben müssen Sie unsafe-inline, denn das erlaubt eingeschleuste Skripte genauso wie Ihre eigenen.
Was passiert mit eingebetteten Karten oder Videos?
Deren Hosts müssen in den Direktiven stehen, die sie nutzen, meist script-src und frame-src. Der Report-Only-Modus ist der günstigste Weg, sie zu finden, denn die Meldung nennt jede Quelle, die blockiert worden wäre.
Ist eine schwache Richtlinie besser als keine?
Eine Richtlinie rund um default-src self ist ein echter Fortschritt, auch wenn sie noch etwas Inline-Code erlaubt. Eine Richtlinie, die überall unsafe-inline und unsafe-eval zulässt, erzeugt vor allem einen Header, der in einem Prüfwerkzeug gut aussieht, ohne einen Angriff zu stoppen.
Wie prüfe ich, ob meine Content Security Policy funktioniert?
Sehen Sie in den Entwicklerwerkzeugen des Browsers an zwei Stellen nach: die Antwort-Header der document-Anfrage zeigen die Richtlinie, die der Browser erhalten hat, und die Konsole listet jede Ressource, die er abgelehnt hat. Trägt der Header den erzwingenden Namen und nicht nur Report-Only, und bleibt die Konsole auf Ihren wichtigen Seiten frei von Verstößen, dann funktioniert die Richtlinie. Unser kostenloser Scan prüft denselben Header von außen und bewertet, wie stark die Richtlinie ist.
Warum zeigt curl keine Content-Security-Policy, obwohl der Browser eine hat?
Meist aus einem von drei Gründen: die Richtlinie steht als Meta-Tag im HTML statt im Header, der Server beantwortet die HEAD-Anfrage von curl -I anders als ein normales GET, oder die URL leitet weiter und Sie haben nur die Header der Weiterleitung gesehen. curl -s -o /dev/null -D - mit der endgültigen URL schließt die letzten beiden aus.
Meine Richtlinie enthält unsafe-inline neben einer Nonce. Ist das eine Schwäche?
Nein. Browser, die Nonces unterstützen, ignorieren unsafe-inline in einer Direktive, die zusätzlich eine Nonce oder einen Hash enthält. Es wirkt dann nur noch in sehr alten Browsern, die Ihre Inline-Skripte sonst blockieren würden. Unser Scanner zählt es in diesem Fall nicht als Schwäche. Ohne Nonce oder Hash in derselben Direktive ist es eine.
07 Im Detail
Verwandte Sicherheitsthemen
Die Richtlinie ist ein Baustein. Diese Ratgeber behandeln die Nachbarn, mit denen sie zusammenarbeitet.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, ob Ihre Richtlinie ihre Aufgabe erfüllt
Unser kostenloser Quickscan liest Ihren ausgelieferten Content-Security-Policy-Header samt Report-Only-Variante und einer im Meta-Tag gesetzten Richtlinie - und erklärt den Befund verständlich.