Mit einer absichtlichen Ablehnung starten
Die Beispielseite ist example.com, das Skript liegt auf cdn.example.com. Lesen Sie script-src und die Fallback-Anzeige, bevor Sie eigene URLs einsetzen.
Web-Sicherheit
Richtlinientext oder Direktiven bearbeiten und Header, Befunde sowie einen Beispielabruf prüfen.
Quelle passt in diesem statischen Beispiel nicht
Keine der modellierten Quellen passt zu dieser Ressourcen-URL.
Wirksame Direktive: script-src · Fallback verwendet
Keine modellierten Befunde. Das ist keine Freigabe für den Einsatz.
6 von 6 Direktiven angezeigt
default-src 'self'script-src 'self'img-src 'self' data:object-src 'none'base-uri 'self'frame-ancestors 'none'Richtlinie, Hosts und Beispiel-URLs bleiben in diesem Browser; es wird keine Anfrage gesendet.
Report-Only beobachtet mögliche Verstöße, blockiert aber nicht. Für Berichte braucht es einen konfigurierten Endpunkt; diese Seite sendet und empfängt keine Berichte.
6 Direktiven · 0 Befunde
Wenn ein fremdes Skript plötzlich nicht lädt, zeigt der CSP-Generator, welche Direktive tatsächlich greift. Das Beispiel fordert auf example.com ein Skript von cdn.example.com an und scheitert bewusst an script-src self. Es ist keine Empfehlung für den Produktivbetrieb.
Als Content-Security-Policy-Header-Generator verbindet die Seite Text und Direktiven in einem Entwurf. Ein CSP Analyzer macht einzelne Risiken sichtbar, statt aus einer unvollständigen Prüfung eine scheinbar verbindliche Sicherheitsnote zu machen.
Der CSP-Generator wählt für einen Ressourcentyp die wirksame Direktive und verwendet default-src nur als passenden Fetch-Fallback. Das CDN-Skript im Beispiel passt nicht zu script-src self; erst ein genauer CDN-Host verändert diese eine statische Aussage.
Ein CSP-Header-Validator sollte erklären, dass none neben anderen Quellen ignoriert wird und bei doppelten Direktiven die erste zählt. Jeder Hinweis bleibt an seiner Direktive; Report-Only wird als Beobachtung statt als Blockade beschrieben.
Die Beispielseite ist example.com, das Skript liegt auf cdn.example.com. Lesen Sie script-src und die Fallback-Anzeige, bevor Sie eigene URLs einsetzen.
Report-Only ändert den Headernamen, blockiert aber keine Ressource. Ohne report-to oder report-uri gibt es hier kein Berichtsziel. Ein erzeugter Nonce wird nicht in den Entwurf eingefügt.
Die automatische Prüfung wartet nach Änderungen 350 ms. Ausgeschaltet helfen Schaltfläche oder Strg/Cmd + Enter. Jede Eingabeänderung sperrt den Export; Leeren und Beispiel laden bieten Vorschau und einmaliges Rückgängigmachen.
Der CSP-Generator akzeptiert den reinen Wert oder eine vollständige CSP-Header-Zeile. Unbekannte Direktiven und die Reihenfolge doppelter Einträge bleiben erhalten; fehlerhafter Text wird nicht heimlich verworfen.
Mit diesem CSP Analyzer lassen sich unsafe-inline, unsafe-eval, *, breite Schemata, fehlende Basisdirektiven und gemischtes none prüfen. Das Tool löscht sie nicht automatisch, weil vorhandene Skripte und Styles sonst ausfallen können.
Die Dokument-URL und eine absolute HTTP(S)-Ressourcen-URL liefern die wirksame Direktive samt Fallback. Pfadquellen, strict-dynamic und Nonce-Kontext ergeben bewusst „nicht entscheidbar“.
Die formatierte Ausgabe bewahrt die Reihenfolge und verwendet Content-Security-Policy oder den Report-Only-Namen. Nach jeder Änderung sind Kopie und Download bis zur Neuberechnung gesperrt.
Schlüsselwörter wie self, none sowie Nonce- und Hash-Quellen stehen in einfachen Anführungszeichen. Schemata wie https: und Hosts wie cdn.example.com stehen ohne solche Zeichen. Der Editor korrigiert Eingaben nicht automatisch.
Er erzeugt den Headernamen Content-Security-Policy-Report-Only. Das beobachtet Verstöße, statt Ressourcen zu sperren. Für echte Berichte muss der Server zusätzlich ein Ziel konfigurieren.
Nein, nicht vollständig. Report-Only und etwa frame-ancestors benötigen einen HTTP-Antwortheader; deshalb exportiert dieses Tool nur einen solchen Header.
Dieses Tool lässt nicht eingegebene Direktiven aus und erhält die vorhandenen. Bei fehlenden Fetch-Direktiven kann default-src greifen; base-uri und frame-ancestors erben ihn nicht.
Nein. Richtlinie, Hosts und Beispiel-URLs werden lokal verarbeitet. Der tatsächliche Server-Header wird nicht abgefragt und muss separat geprüft werden.
Noch einen Fall prüfen?
Eine Ressourcen-URL vergleichen, wirksame Direktive und Befunde lesen und erst dann den aktuellen Header kopieren.