Was CSP leistet
Eine durchgesetzte Skriptpolicy kann die Ausführung eingeschleuster Skripte einschränken. Sie behebt jedoch keine fehlerhafte Eingabeverarbeitung und macht erlaubte Skripte nicht automatisch sicher. Eingabeprüfung, kontextgerechte Ausgabe und sichere DOM-Verarbeitung bleiben erforderlich. CSP ist eine zusätzliche Schutzebene. W3C: Einführung in CSP
Entscheidend sind die tatsächlich wirksamen Direktiven. Eine Policy mit ausschließlich frame-ancestors regelt, wer die Seite einbetten darf; sie begrenzt keine Skriptausführung. Ein vorhandener Header allein sagt daher wenig über den gesamten Schutzumfang aus.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Begriff | Bedeutung | Grenze |
|---|---|---|
enforce | Eine Policy im Header Content-Security-Policy wird durchgesetzt. | Der Browser blockiert nur Aktionen, die ihre wirksamen Regeln verletzen. |
report | Content-Security-Policy-Report-Only lässt Regeln zunächst beobachten. | Diese Policy blockiert nicht; andere durchgesetzte Policies bleiben wirksam. |
AND | Mehrere durchgesetzte Policies gelten gemeinsam. | Eine zusätzliche Freigabe hebt eine Sperre in einer anderen Policy nicht auf. |
Der Wolf-Agents Web Security Check untersucht CSP-Header der abgerufenen Antwort. Das ist keine Ausführung aller Skripte, kein Pentest und keine Prüfung aller Unterseiten. Nonce-Erzeugung, sichere Trusted-Types-Policies und die Verträglichkeit im Browser benötigen eigene Prüfungen. Ein solcher Einzelbefund kann für Ihre erste Konfigurationsfrage bereits genügen.
Welche XSS-Risiken eine Skriptpolicy begrenzen kann
Wenn eine Anwendung eine XSS-Lücke hat, kann eingeschleustes JavaScript beispielsweise Seitentexte verändern, Eingaben mitlesen oder auf Daten zugreifen, die JavaScript im betreffenden Kontext erreichen kann. Das kann auch Formulare und täuschende Anmeldemasken betreffen. Ein HttpOnly-Cookie ist für JavaScript nicht direkt lesbar; dieses Attribut beseitigt aber nicht die übrigen Folgen von XSS. OWASP: Cross Site Scripting
Eine passende, durchgesetzte CSP kann den betroffenen Ausführungsweg blockieren, bevor das eingeschleuste Skript läuft. Voraussetzung ist, dass der Browser die entsprechende Regel unterstützt und das Skript keine Freigabe über eine wirksame Quelle, einen Nonce, einen Hash oder einen erlaubten dynamischen Ladeweg erhält. Erlaubter, aber unsicherer Code bleibt ein Risiko.
Bedingte Fälle · keine Bewertung der gesamten Anwendung
Situation und Aussage gemeinsam lesen
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Situation | Was sich daraus ableiten lässt |
|---|---|
| Eine XSS-Lücke besteht, eine wirksame Skriptbegrenzung fehlt. | CSP stellt an diesem Ausführungsweg keine zusätzliche Sperre bereit. Das ist noch kein Nachweis einer ausnutzbaren Lücke auf einer bestimmten Seite. |
| Ein Skript verletzt eine durchgesetzte, unterstützte Regel. | Der Browser blockiert den von dieser Regel erfassten Vorgang. Das ist keine Aussage über alle anderen Ausführungswege. |
| Ein CSP-Bericht trifft ein. | Ein berichteter Regelverstoß lässt sich untersuchen. Der Bericht allein beweist keinen Angriff. |
| Ein Headercheck findet eine Policy. | Die untersuchte Antwort enthält diese Konfiguration. Die gesamte Anwendung ist damit nicht abgenommen. |
HTTP-Header, Meta und mehrere Policies unterscheiden
Der HTTP-Antwortheader ist der bevorzugte Auslieferungsweg. Kontrollieren Sie, ob Anwendung, Webserver und CDN jeweils eine Policy hinzufügen. Maßgeblich ist die Antwort, die beim Browser ankommt.
Zwei durchgesetzte Policies werden nicht zu einer großzügigen gemeinsamen Allowlist zusammengefügt. Das folgende Modell enthält absichtlich einen Widerspruch:
Content-Security-Policy: connect-src 'none'
Content-Security-Policy: connect-src https://api.example.comEine Verbindung zu https://api.example.com bleibt durch die erste Policy gesperrt. Die zweite kann sie nicht freigeben. Auch eine zusätzliche Report-Only-Policy lockert eine vorhandene Sperre nicht. Das Beispiel erklärt die Regeln; es ist kein gemessener Antwortmitschnitt. W3C: mehrere Policies
Eine CSP kann auch in einem HTML-meta-Element stehen. Dieser Weg hat Grenzen: keine Report-Only-Policy, keine wirksamen Direktiven frame-ancestors, sandbox oder report-uri, und keine rückwirkende Sperre für Inhalte vor dem Meta-Element. Eine Meta-Policy gilt zusätzlich zu anderen Policies. Verwenden Sie sie nicht als gleichwertigen Ersatz für einen vollständigen Headeranschluss. W3C: Meta-Auslieferung
Eine CSP in drei Schritten einführen
1. Eine erste Policy ohne neue Durchsetzung ausliefern
Ermitteln Sie zuerst die benötigten Skripte, Stile, Bilder, Fonts, API-Verbindungen und eingebetteten Inhalte. Klären Sie außerdem, welche Stelle die Header setzt. Eine neue oder strengere Policy lässt sich zunächst als Report-Only-Policy ergänzen, während eine vorhandene durchgesetzte Basis bestehen bleibt.
Die folgenden Ausschnitte zeigen die Konfigurationsform für Nginx beziehungsweise Apache. Sie sind nicht ausgeführt und keine universellen Produktionsvorlagen. example.com und /api/csp-report stehen für ein von Ihnen eingerichtetes Berichtsziel; der Header erstellt keinen Empfänger.
Nginx: Der passende http-, server- oder location-Kontext und die wirksame Headervererbung müssen zur Auslieferung passen. always erweitert die Ausgabe auf andere Antwortcodes, ersetzt aber keine Prüfung der Konfigurationsstruktur. Nginx: Header-Modul
add_header Reporting-Endpoints 'csp-endpoint="https://example.com/api/csp-report"' always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; report-uri /api/csp-report; report-to csp-endpoint" always;Apache: Der Ausschnitt setzt mod_headers voraus. In .htaccess muss die Konfiguration dort auch zulässig sein, etwa über AllowOverride FileInfo. Ohne geladenes Modul wird der Inhalt von IfModule übersprungen. always und die normale Headertabelle sind getrennt; prüfen Sie vorhandene Header von Anwendung und Proxy auf Doppelungen. Apache: Header-Direktive
<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; report-uri /api/csp-report"
</IfModule>Beide Beispiele erlauben in ihrem Regelmodell breite Bildquellen über https: und Inline-Stile über 'unsafe-inline'. Das erleichtert hier die Erklärung, ist aber keine Empfehlung, diese Freigaben unverändert zu übernehmen. Für Skripte ist 'unsafe-inline' nicht gesetzt. Report-Only blockiert die modellierten Verstöße noch nicht.
2. Verstöße zuordnen und Funktionen prüfen
Öffnen Sie die Entwicklerwerkzeuge Ihres Browsers, häufig über F12. Vergleichen Sie die CSP-Meldung mit der ausgelieferten Policy, der betroffenen Seite und der auslösenden Aktion. Prüfen Sie repräsentative Wege einschließlich Anmeldung, Formularen und gegebenenfalls Checkout; die Startseite allein genügt dafür nicht.
Fügen Sie eine gemeldete Domain nicht automatisch hinzu. Entscheiden Sie zuerst, ob die Ressource benötigt wird, woher sie kommt und welche Direktive tatsächlich greift.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Meldung oder Ressource | Nächste Entscheidung |
|---|---|
| Inline-Skript | Gehört es zur Anwendung? Wenn ja, kommen ein gezielter Nonce, ein Hash oder eine andere Einbindung infrage. Fremden oder eingeschleusten Code nicht nachträglich autorisieren. |
| Externe Bibliothek | Zweck und konkrete Ladequelle prüfen. Eine große CDN-Allowlist kann mehr Code erlauben als beabsichtigt. |
| Google Fonts | Stylesheets und Fontdateien getrennt betrachten: fonts.googleapis.com und fonts.gstatic.com stehen für unterschiedliche Ressourcenrollen, nicht für eine vollständige aktuelle Anbieteranleitung. |
| Analytics oder Tag-Manager | Skripte und Netzwerkaufrufe passenden Direktiven zuordnen. Wildcards wie *.google-analytics.com oder *.googletagmanager.com nicht allein wegen einer Meldung übernehmen. |
Für zentrale Berichte muss die gesamte Strecke funktionieren. report-to verweist auf einen Namen in Reporting-Endpoints; report-uri ist der ältere, als veraltet gekennzeichnete Weg. Unterstützt ein Browser report-to, ignoriert er report-uri in derselben Policy. Welche Form Sie benötigen, richtet sich nach Ihren Zielbrowsern und dem Empfänger. Ein Konsoleneintrag oder ein eingetragener Endpoint beweist keine zugestellte Meldung. MDN: report-to
3. Geprüfte Regeln durchsetzen und einen Rückweg behalten
Stellen Sie die neue Fassung erst um, wenn die benötigten Funktionen und der Berichtsweg im vorgesehenen Umfang geprüft sind. Sichern Sie die bisherige Konfiguration und legen Sie fest, wer bei Problemen die letzte bekannte funktionsfähige Policy wiederherstellt.
Content-Security-Policy-Report-Only → Content-Security-PolicyDer Wechsel betrifft den Headernamen und die tatsächlich ausgelieferte Fassung an den verantwortlichen Stellen. Ein zusätzlich gesetzter Header ersetzt vorhandene Policies nicht automatisch. Behalten Sie auch nach der Umstellung aussagekräftige Funktionstests und eine bedarfsgerechte Auswertung von Verstößen bei. Der Rollout-Ratgeber beschreibt die Entscheidungspunkte genauer.
Die wichtigsten Direktiven lesen
Diese Tabelle ist eine Orientierung, keine fertige Policy. Werte wie 'self', 'none', data: oder https: müssen zum vorgesehenen Vorgang passen. 'self' bezieht sich auf die eigene Origin, nicht pauschal auf alle Subdomains.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Direktive | Gesteuerter Bereich | Einordnung möglicher Werte |
|---|---|---|
default-src | Rückfallregel für erfasste Fetch-Direktiven, die nicht eigens gesetzt sind | Beispielsweise 'self'; kein Ersatz für jede CSP-Direktive. |
script-src | Skriptquellen und zugehörige Ausführungsregeln | Nonces oder Hashes können gezielt Skripte autorisieren; eine Hostfreigabe ist keine Inhaltsprüfung. |
style-src | Stylesheets und Inline-Stile | Beispielsweise 'self'; 'unsafe-inline' erlaubt mehr Inline-Stile und ist eine bewusste Öffnung. |
img-src | Bilder | 'self', data: oder konkrete externe Quellen; https: ist eine breite Schemafreigabe. |
font-src | Fontdateien | Eigene und tatsächlich benötigte externe Fontquellen. |
connect-src | Unter anderem Fetch, XMLHttpRequest, WebSocket und EventSource | Benötigte API- und Verbindungsziele; WebSocket-Wege eigens berücksichtigen. |
frame-ancestors | Welche Vorfahren die Seite einbetten dürfen | Zum Beispiel 'self' oder 'none'; etwas anderes als frame-src, das eingebettete Frames der Seite regelt. |
object-src | Über object oder embed geladene Inhalte | 'none', sofern diese Einbettungen nicht benötigt werden. |
base-uri | Zulässige Basis-URL aus einem base-Element | 'self' oder 'none' begrenzen die Umdeutung relativer URLs. |
form-action | Ziele von Formularübermittlungen | Beispielsweise 'self', soweit keine anderen Ziele erforderlich sind. |
Eine explizite Direktive ersetzt für ihren Bereich den Rückfall auf default-src; sie ergänzt dessen Quellen nicht. Eine vorhandene Direktive mit leerer Quellenliste blockiert den erfassten Kontext bei Durchsetzung und löst keinen Rückfall aus. script-src-elem kann Skriptelemente und script-src-attr Ereignisattribute genauer regeln. Fehlen sie, verläuft ihr Rückfall über script-src zu default-src. Für eval() ist dagegen script-src maßgeblich, ersatzweise default-src. W3C: Direktiven und Rückfallregeln, JavaScript-Auswertung
frame-ancestors, base-uri und form-action haben keinen solchen Rückfall auf default-src. Auch default-src selbst ist keine Pflichtdirektive: Eine gezielte Strict CSP kann Skripte, Objekte und die Basis-URL ausdrücklich begrenzen. Daraus folgt jedoch keine Beschränkung aller anderen Ressourcenarten. W3C: Strict CSP
Prüfen Sie bei einer konkreten Meldung immer die effektive Direktive, nicht nur die erste Zeile Ihrer Konfiguration.
Nonces, Hashes und strict-dynamic bewusst einsetzen
Ein Nonce markiert ausgewählte Skript- oder Stilelemente, die Sie autorisieren. Bei jeder übermittelten Policy muss ein neuer Wert entstehen; empfohlen sind mindestens 128 Bit aus einem kryptographisch sicheren Zufallsgenerator. Header und autorisierte Elemente derselben Antwort müssen zusammenpassen. Ein statischer Wert zum Kopieren erfüllt diese Aufgabe nicht. Für unveränderliche Skriptinhalte können Hashes besser zur Auslieferung passen. W3C: Nonce-Anforderungen
Regelmodelle · kein ausgeführter Test
Zwei Wege zur Skriptfreigabe
NONCE_VALUE ist ein sichtbarer Platzhalter, kein geeigneter Produktionstoken.
Nonce und ausdrückliche Quellen
script-src 'nonce-NONCE_VALUE' 'self' cdn.jsdelivr.net unpkg.com cdnjs.cloudflare.com ajax.googleapis.com;Ein Nonce und konkrete Skriptquellen gehören zur wirksamen Quellenliste.
Nonce oder Hash und strict-dynamic
script-src 'nonce-NONCE_VALUE' 'strict-dynamic';In unterstützenden Browsern werden Host- und Schemafreigaben sowie 'self' und 'unsafe-inline' für diese Skriptauswertung ignoriert.
Nur im zweiten Modell, bei Browserunterstützung:
Zum Beispiel über document.createElement('script').
document.write() gehört nicht zu diesem dynamischen Freigabepfad. Die Freigabe prüft keinen Dateiinhalt. MDN: strict-dynamic
strict-dynamic ist deshalb keine pauschale Verbesserung für jede Anwendung. Es überträgt Verantwortung auf die autorisierten Ladeprogramme: Wenn diese eine vom Angreifer steuerbare Skript-URL verwenden, kann die Policy diesen Nachladevorgang erlauben. Verwenden Sie den Mechanismus nur, wenn Sie ihn benötigen und die Ladewege kontrollieren. Eine Skriptfreigabe garantiert weder unbedenklichen Inhalt noch Integrität einer externen Datei. W3C: dynamische Ladewege
Die dokumentierte Unterstützung von strict-dynamic beginnt bei Chrome 52, Firefox 52 und Safari 15.4; für Chromium-basiertes Edge ist sie ebenfalls dokumentiert. Diese historischen Einstiegsversionen ersetzen keine Prüfung Ihrer heutigen Zielbrowser und eingebetteten Browser. MDN: Kompatibilitätsdaten
Für die konkrete Umsetzung lesen Sie Nonces und Caches.
Sicherheitsmaßnahme und Nachweis auseinanderhalten
Die folgenden Bezüge betreffen ihren jeweiligen Anwendungsbereich. Sie begründen keine weltweit gleiche Pflicht, einen bestimmten CSP-Header zu setzen.
NIS2 und deutsches BSIG: § 30 BSIG erfasst unter anderem die Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen. Für erfasste Einrichtungen verlangt § 38 die Umsetzung und Überwachung der Risikomanagementmaßnahmen durch die Geschäftsleitung. Bei schuldhafter Pflichtverletzung kann eine Haftung gegenüber der eigenen Einrichtung entstehen. Daraus folgt kein allgemeines CSP-Zertifikat und keine automatisch persönliche Haftung für einen fehlenden Header. BSIG § 30, BSIG § 38
PCI DSS 4.0.1: Bei relevanten Zahlungsseiten betreffen die Anforderungen 6.4.3 und 11.6.1 unter anderem Skriptautorisierung, Integrität, Inventar und das Erkennen von Manipulationen. CSP und Subresource Integrity können Teile eines passenden Ansatzes sein. Ein Header ersetzt weder das Inventar noch die erforderlichen laufenden Kontrollen oder den Nachweis im konkreten Prüfungsumfang. PCI SSC: Sicherheit von Zahlungsseiten
Datenschutz: Artikel 32 DSGVO verlangt ein dem Risiko angemessenes Schutzniveau durch technische und organisatorische Maßnahmen. CSP kann bestimmte Browserrisiken begrenzen; sie belegt allein keine Datenschutzkonformität. EUR-Lex: DSGVO, Artikel 32
Die vorhandenen Ratgeber zur NIS2-Checkliste und Geschäftsführerhaftung ordnen den deutschen Kontext weiter ein.
Den passenden nächsten Schritt wählen
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Ihre Aufgabe | Vertiefung |
|---|---|
| Neue Regeln ausrollen | Report-Only, Prüfungen und Enforcement |
| Skripte gezielt autorisieren | Nonces |
| Eine Meldung zuordnen | Direktiven |
Wenn Sie zunächst die öffentlich erreichbare Konfiguration Ihrer Domain einordnen möchten, öffnen Sie den Web Security Check. Berücksichtigen Sie den dort ausgewiesenen Messumfang; ein CSP-Befund ersetzt die oben beschriebenen Funktions- und Berichtsprüfungen nicht.
Häufige Fragen
Was ist Content Security Policy (CSP)?
CSP legt Regeln für ausgewählte Browseraktionen fest, etwa Skriptausführung, Ressourcen und Einbettungen. Der tatsächliche Umfang hängt von den wirksamen Direktiven ab. Sie ergänzt sichere Programmierung und ist kein vollständiger XSS-Schutz.
Schützt CSP vor allen XSS-Angriffen?
Nein. Nonces oder Hashes können nicht autorisierte Skripte blockieren, machen aber erlaubten Code nicht automatisch sicher. Trusted Types kann bestimmte DOM-Schnittstellen zusätzlich absichern, sofern der Browser die Anforderung durchsetzt und die zugehörigen Policies Eingaben sicher verarbeiten.
Kann CSP meine Website beeinträchtigen?
Ja. Eine durchgesetzte Policy kann benötigte Ressourcen oder Aktionen blockieren. Erproben Sie neue Regeln zunächst mit Report-Only und repräsentativen Funktionstests. Bereits durchgesetzte Policies bleiben dabei aktiv.
Was unterscheidet Report-Only und Enforcement?
Eine Report-Only-Policy wird beobachtet, aber nicht durchgesetzt. Eine Enforcement-Policy blockiert die Vorgänge, die ihre wirksamen Regeln verletzen. Weder eine verstrichene Woche noch das Ausbleiben von Reports beweist, dass die Umstellung funktioniert.
Brauche ich CSP, wenn bereits eine WAF vorhanden ist?
Eine Web Application Firewall prüft Verkehr nach ihren Regeln; CSP setzt Regeln im Browser durch. Beide können sich ergänzen. Welche Maßnahmen sinnvoll sind, hängt von Ihrer Anwendung ab. Eine WAF macht eine passende CSP nicht automatisch überflüssig und garantiert keine Erkennung aller Angriffe.
Ist CSP für NIS2-Compliance vorgeschrieben?
NIS2 nennt CSP nicht als universell vorgeschriebenen Header. Eine passende CSP kann eine technische Maßnahme ergänzen. Ein Headercheck belegt keine vollständige Erfüllung gesetzlicher oder organisatorischer Anforderungen.