CSP auswerten
CSP auswerten ohne Rätselraten: Fügen Sie eine Content-Security-Policy ein, und das Werkzeug zerlegt die Direktiven, zeigt die wirksame Regel je Ressourcentyp und markiert Schwachstellen.
| Direktive | Quellen | Bedeutung |
|---|
| Ressourcentyp | Greifende Direktive | Erlaubte Quellen |
|---|
Alles läuft in Ihrem Browser. Eingaben verlassen Ihr Gerät nicht.
Content-Security-Policy verstehen und bewerten
Mit diesem Werkzeug CSP auswerten heißt: Sie fügen eine vorhandene Content-Security-Policy ein, und der Prüfer zerlegt sie in ihre CSP-Direktiven, zeigt je Ressourcentyp die tatsächlich greifende Regel und bewertet typische Schwachstellen. Die Content-Security-Policy prüfen lohnt sich vor allem bei geerbten Konfigurationen: Oft steht dort 'unsafe-inline' in script-src, ein Sternchen bei den Quellen oder ein großes CDN, über das sich beliebige Skripte nachladen lassen. Dann schützt die Policy kaum noch vor Cross-Site-Scripting.
Die Bewertung folgt den Regeln aus CSP Level 3: Fehlt eine Fetch-Direktive wie img-src, gilt default-src; script-src-elem fällt auf script-src zurück, worker-src über child-src und script-src auf default-src. base-uri, form-action und frame-ancestors erben dagegen nichts. Stehen Nonces oder Hashes in der Liste, ignorieren aktuelle Browser 'unsafe-inline'; mit 'strict-dynamic' werden zusätzlich Hostnamen und Schemata wie https: ignoriert, und nur Skripte mit gültiger Nonce dürfen weitere Skripte laden. Diese Kombination gilt als robuste Form einer CSP.
Grenzen: Der Prüfer sieht nur den Text der Policy, nicht Ihre Seite. Ob eine erlaubte Domain tatsächlich JSONP-Endpunkte oder alte Bibliotheken anbietet, lässt sich offline nur als Hinweis bewerten. Ob die Nonce bei jeder Antwort neu erzeugt wird, kann er ebenfalls nicht prüfen. Eine neue Policy bauen Sie mit dem CSP-Generator; alle übrigen Antwort-Header bewertet der Sicherheits-Header-Prüfer.
Anleitung: CSP auswerten in 4 Schritten
- Den Header oder das meta-Tag in das Feld „Content-Security-Policy einfügen“ kopieren, mit oder ohne
Content-Security-Policy:davor. - Bei „Ausgeliefert als“ angeben, ob die Policy per HTTP-Header oder per
<meta http-equiv>kommt. - Die Bewertung lesen: rote Punkte zuerst beheben, gelbe Punkte prüfen.
- In der Tabelle „Wirksame Regel je Ressourcentyp“ nachsehen, welche Direktive für Skripte, Bilder oder Frames tatsächlich greift.
Typische Anwendungsfälle
- Eine geerbte oder von einem Plugin gesetzte CSP verstehen, bevor man sie ändert.
- Nach einem Penetrationstest nachvollziehen, warum eine Policy als zu locker gilt.
- Vor dem Umstieg von Report-Only auf eine erzwungene Policy die Lücken finden.
- Die CSP großer Websites als Vorbild lesen und die Unterschiede zur eigenen sehen.
Häufige Fragen
Warum ist 'unsafe-inline' in script-src gefährlich?
Es erlaubt jedes Inline-Skript und jeden Event-Handler wie onclick. Gelingt einem Angreifer eine HTML-Injektion, führt der Browser den eingeschleusten Code aus; die CSP verliert damit ihren wichtigsten Schutz gegen Cross-Site-Scripting.
Was bewirkt 'strict-dynamic'?
Skripte, die mit gültiger Nonce oder passendem Hash geladen wurden, dürfen weitere Skripte nachladen. Gleichzeitig ignoriert der Browser Hostnamen, Schemata und 'unsafe-inline' in script-src. So muss man keine langen Domainlisten pflegen.
Warum wird object-src 'none' empfohlen?
Über object und embed konnten früher Plugins Code ausführen. Ohne object-src gilt default-src, das oft mehr erlaubt als nötig. object-src 'none' schließt diesen Weg, ohne normale Seiten zu stören.
Welche Direktiven funktionieren nicht im meta-Tag?
frame-ancestors, report-uri und sandbox werden in einer per meta-Tag gesetzten Policy ignoriert. Report-Only gibt es als meta-Tag gar nicht. Für diese Fälle muss die Policy als HTTP-Header kommen.
Ist eine CSP mit Hostnamen-Liste sicher?
Sie ist besser als keine, aber schwer dicht zu bekommen. Erlaubt die Liste große CDNs oder Dienste mit JSONP-Schnittstellen, kann ein Angreifer darüber eigenen Code laden. Nonces mit 'strict-dynamic' sind deshalb robuster.
Warum greift meine img-src nicht für Schriftarten?
Jede Fetch-Direktive gilt nur für ihren Ressourcentyp. Für Schriftarten ist font-src zuständig; fehlt sie, gilt default-src. img-src wird nie für andere Typen herangezogen.
Kann eine CSP aus mehreren Headern bestehen?
Ja. Mehrere Content-Security-Policy-Header oder durch Komma getrennte Policies gelten alle gleichzeitig. Eine Ressource muss jede Policy erfüllen, die Policies werden also nur strenger, nie lockerer.
Das könnte auch helfen
Hash-Generator
MD5, SHA-1, SHA-256, SHA-384 und SHA-512 für Text oder Datei berechnen und vergleichen.
ÖffnenHMAC-Generator
HMAC mit SHA-256, SHA-512, SHA-1 oder MD5 berechnen und Webhook-Signaturen prüfen.
ÖffnenPasswort-Generator
Sichere Zufallspasswörter mit wählbarer Länge und Zeichengruppen, inklusive Entropie in Bit.
ÖffnenPasswort-Stärke prüfen
Passwort testen: Entropie, typische Muster, häufige Passwörter und grobe Knackzeit.
ÖffnenPassphrase-Generator
Merkbare Passphrasen aus einer deutschen Wortliste mit über 2.000 Wörtern, nach Diceware-Art.
ÖffnenToken-Generator
Zufalls-Token als Hex, Base64URL oder alphanumerisch erzeugen, etwa für API-Keys und Secrets.
Öffnen