Prüfen Sie eine Content-Security-Policy Direktive für Direktive und sehen Sie, wie Skripte sie umgehen
Läuft in Ihrem Browser. Nichts, was Sie eingeben, wird irgendwohin gesendet. Geprüft am 16. Oktober 2026.Eine Content-Security-Policy teilt dem Browser mit, von wo Skripte und andere Inhalte geladen werden dürfen. Sie schützt nur dann vor eingeschleusten Skripten, wenn script-src auf 'unsafe-inline', Wildcards und umgehbare Hosts verzichtet, object-src 'none' ist und base-uri eingeschränkt ist. Eine Google-Studie von 2016 ergab, dass 94.7% der realen Richtlinien umgangen werden konnten; Nonces mit 'strict-dynamic' beheben das.
Diese Seite wurde maschinell aus dem englischen Original übersetzt. Die Übersetzung wurde noch von keinem Menschen geprüft; maßgeblich ist die englische Fassung. Englisches Original lesen
Fügen Sie die Richtlinie, die ganze Content-Security-Policy-Headerzeile oder das <meta>-Tag ein, das sie enthält.
Lesen Sie die Befunde, die schwersten zuerst: Jeder nennt die Direktive und was ein Angreifer damit tun könnte.
Prüfen Sie die Tabelle der Direktiven auf falsch geschriebene Namen und Quellen, die der Browser ignoriert.
Korrigieren Sie die Richtlinie oder beginnen Sie mit dem strikten Template, und fügen Sie sie erneut ein, bis nur noch Hinweise übrig sind.
Bei einer Content-Security-Policy schleichen sich leicht kleine Fehler ein, und Browser beschweren sich nie: Eine Direktive, die sie nicht lesen können, wird ignoriert. Dieses Tool liest die Richtlinie genau so, wie ein Browser es laut der Spezifikation CSP Level 3 tut, und bewertet sie anhand der Ergebnisse von Googles Studie realer Richtlinien aus dem Jahr 2016.
Befunde, die schwersten zuerst.
| Schweregrad | Beispiele |
|---|---|
| Hoch | 'unsafe-inline' ohne Nonce, * oder https: in script-src, object-src nicht 'none', 'strict-dynamic' ohne Nonce, ein fehlendes Semikolon, self ohne Anführungszeichen |
| Mittel | 'unsafe-eval', freigegebene Hosts, die bekanntermaßen JSONP oder altes AngularJS ausliefern, offenes base-uri, reine http-Quellen, unbekannte Direktiven |
| Niedrig | kein frame-ancestors, kurze Nonces, veraltete Direktiven, Duplikate, 'unsafe-inline' für Styles |
| Hinweis | kein Reporting, report-uri ohne report-to, Quellen, die Browser bei einer strikten Richtlinie ignorieren |
Fallback wird angewendet. Fehlt script-src, wird stattdessen default-src bewertet; fehlen beide, dürfen Skripte von überall geladen werden, und das Tool weist darauf hin.
Fügen Sie alles ein. Die reine Richtlinie, die ganze Headerzeile oder ein <meta http-equiv>-Tag. Richtlinien in einem Meta-Tag können frame-ancestors, report-uri und sandbox nicht nutzen, und das Tool markiert diese. Ein Header mit mehreren durch Kommas getrennten Richtlinien wird aufgeteilt, da jede einzelne durchgesetzt wird.
Jede Quelle wird geprüft. Schlüsselwörter, Nonces, Hashes (mit der richtigen Länge für SHA-256, 384 oder 512), Schemata und Hosts werden gegen die Grammatik geprüft, und zu einer falsch geschriebenen Direktive gibt es einen Vorschlag, etwa frame-ancestor zu frame-ancestors.
Striktes Template. Ein Tippen lädt eine Nonce-basierte Richtlinie: script-src mit einer Nonce und 'strict-dynamic', object-src 'none' und base-uri 'none'. Ihr Server muss bei jeder Antwort eine neue zufällige Nonce in den Header und in jedes Script-Tag schreiben.
Die Richtlinie wird in Ihrem Browser gelesen und nirgendwohin gesendet. Um die Header abzurufen, die eine Live-Website sendet, verwenden Sie den HTTP Headers Checker.
Nein. Mit 'unsafe-inline' wird jedes Skript ausgeführt, das ein Angreifer in die Seite einschleusen kann, und genau das soll eine Content-Security-Policy verhindern. Verwenden Sie stattdessen für jedes Inline-Skript eine Nonce oder einen Hash. Sobald eine Nonce oder ein Hash vorhanden ist, ignorieren moderne Browser 'unsafe-inline', daher schadet es nicht, es als Fallback für alte Browser beizubehalten.
Das Schlüsselwort 'strict-dynamic' erlaubt einem Skript, das über eine Nonce oder einen Hash als vertrauenswürdig gilt, weitere Skripte zu laden, während Host-Allowlists und https: von Browsern, die es unterstützen, ignoriert werden. Zusammen mit einer Nonce ergibt das eine Richtlinie, die sowohl strikt als auch einfach einzuführen ist. Ohne Nonce oder Hash blockiert es jedes Skript.
Plugins, die mit object- oder embed-Tags geladen werden, können Skripte außerhalb der Regeln von script-src ausführen, und alte Flash-Dateien auf erlaubten Hosts waren eine häufige Umgehung. Nur noch wenige Websites benötigen Plugins, daher schließt object-src 'none' diesen ganzen Weg. Fehlt object-src, gilt default-src, das oft nicht 'none' ist.
Beliebte Skript-Hosts wie große CDNs und einige Google-Domains stellen JSONP-Endpunkte oder alte AngularJS-Versionen bereit. Ein Angreifer, der Markup einschleusen kann, kann diese erlaubten Dateien laden, um eigenen Code auszuführen. Googles Studie von 2016 ergab, dass 94.7% der realen Allowlist-Richtlinien auf diese Weise umgehbar waren; Nonces mit 'strict-dynamic' vermeiden das Problem.
Der Browser ignoriert die Direktive und protokolliert eine Warnung in der Konsole, aber der Rest der Richtlinie gilt weiter, sodass die Seite diesen Schutz unbemerkt verliert. Ein Tippfehler wie frame-ancestor statt frame-ancestors lässt die Seite offen für Clickjacking. Dieses Tool listet unbekannte Direktiven auf und schlägt den Namen vor, den Sie wahrscheinlich meinten.
Ja, mit einem meta-http-equiv-Tag im Head der Seite, aber drei Direktiven funktionieren dort nicht: frame-ancestors, report-uri und sandbox. Richtlinien in einem Meta-Tag gelten außerdem nur für Inhalte nach dem Tag. Die Richtlinie als HTTP-Antwort-Header zu senden ist die zuverlässige Wahl; das Meta-Tag eignet sich für statisches Hosting ohne Kontrolle über die Header.
Sätze und Regeln ändern sich; prüfen Sie die Quelle, bevor Sie sich auf eine Zahl verlassen.
Kommen Sie nicht weiter? Fragen Sie zu CSP-Prüfer und jeder, der es weiß, kann antworten. Kein Konto nötig.