Kostenlos · ohne Anmeldung
Content Security Policy erstellen und testen
Entwerfen Sie einen Content-Security-Policy-Header oder prüfen Sie konkrete Ressourcen gegen eine vorhandene Policy. Sehen Sie, welche Quellregel greift und wann zusätzlicher Browser-Kontext erforderlich ist.
Policy vorbereiten
Ihr Ergebnis
Eine CSP passend zu Ihrer Website entwerfen
Die Vorgabe erlaubt eigene Ressourcen und beschränkt eingebettete Objekte. Ergänzen Sie benötigte Quellen getrennt für Skripte, Styles, Bilder, Fonts, Verbindungen und Frames. Tragen Sie nur tatsächlich verwendete Dienste ein. Eine fremde Domain in img-src erlaubt noch keine Skripte von derselben Domain. Der Generator verändert Ihren Server nicht.
Mit Report-Only beginnen
Der erste Entwurf verwendet Content-Security-Policy-Report-Only. Damit können Sie Meldungen in der Browserkonsole prüfen, ohne Ressourcen zu blockieren. Ein zentraler Reporting-Endpunkt wird nicht eingerichtet. Nach Tests von Navigation, Formularen, Login und eingebetteten Diensten können Sie bewusst einen blockierenden Header erzeugen. Inline-Skripte und -Styles benötigen eigene Freigaben; ein universeller Header für jede Website existiert nicht.
Wie der Policy-Tester entscheidet
Geben Sie die URL der geschützten Seite, den Ressourcentyp und bis zu 50 Beispiel-URLs ein. Der Tester berücksichtigt Quelllisten, Pfade, Protokolle und Direktiven-Fallbacks. Mehrere erzwingende Policies wirken gemeinsam: Eine Freigabe hebt eine Sperre aus einer anderen Policy nicht auf. Report-Only-Policies werden separat angezeigt. Die erste gleichnamige Direktive innerhalb einer Policy gilt.
Nonce, Hash und strict-dynamic richtig einordnen
Für Inline-Inhalte können Sie eine vorhandene Nonce- oder Hash-Quelle angeben. Ein Treffer setzt voraus, dass der Wert tatsächlich zum Element oder Inhalt gehört. Nonces müssen pro Serverantwort kryptografisch zufällig neu entstehen. Bei externen Skripten mit strict-dynamic können die ladende Skriptkette und Integritätsmetadaten entscheidend sein; dann meldet das Tool einen offenen Kontext statt einer pauschalen Freigabe.
Eine Quellprüfung ist kein vollständiger Browser-Test
Das Tool simuliert direkte Ressourcenanforderungen nach den ausgewählten CSP-Quellregeln. CORS, Redirects, sandbox, Trusted Types und weitere Browserregeln können zusätzlich blockieren. Event-Handler, eval und die gesamte Vorfahrenkette eingebetteter Seiten werden nicht simuliert. Die fachliche Grundlage bildet die CSP-Spezifikation des W3C.
Beispiel zur Einordnung
Bei default-src 'self'; img-src 'self' https://bilder.example.org; ist ein Bild von bilder.example.org erlaubt. Ein Skript derselben Domain bleibt ohne passende script-src-Freigabe gesperrt.
Häufige Fragen
Wird eine Website dafür aufgerufen?
Nein. Generator und Tester arbeiten lokal mit Ihren Eingaben. Es wird kein Header automatisch veröffentlicht.
Warum wird trotz Freigabe Kontext erforderlich angezeigt?
Einige Entscheidungen hängen von Nonces, SRI oder der ladenden Skriptkette ab. Eine URL allein reicht für diese Fälle nicht.
Kann ich mehrere CSP-Header prüfen?
Ja. Fügen Sie jeden vollständigen Content-Security-Policy- oder Content-Security-Policy-Report-Only-Header in eine eigene Zeile ein.
Seitenreport SEO Suite: Ihre Website als Ganzes prüfen
Prüfen Sie bis zu 20 URLs kostenlos. Für wiederkehrende Kontrollen und Veränderungen Ihrer Website lernen Sie die SEO Suite kennen.