Was Sie vor dem Rollout unterscheiden müssen
Eine durchgesetzte Content Security Policy blockiert Vorgänge, die ihre wirksamen Regeln verletzen. Dazu können auch benötigte Skripte, Stile oder API-Aufrufe gehören. Ein schrittweises Vorgehen hilft, solche Konflikte vor einer breiteren Umstellung zu erkennen; es garantiert keine störungsfreie Einführung.
Content-Security-Policy-Report-Only wird beobachtet, aber nicht durchgesetzt. Das bedeutet nur, dass diese Policy nicht blockiert. Eine gleichzeitig geltende Content-Security-Policy bleibt aktiv. Mehrere durchgesetzte Policies müssen alle erfüllt sein; eine zusätzliche Policy mit mehr Quellen lockert eine bestehende Sperre nicht. Report-Only lässt sich nicht über ein HTML-meta-Element ausliefern. W3C: Header und mehrere Policies
Ein einfacher Seitenaufruf kann unauffällig sein, während ein Dialog, ein Passwort-Reset oder ein später geladenes Skript Probleme auslöst. Fehlende Reports beweisen keine Fehlerfreiheit: Der Ablauf kann ungeprüft sein oder die Meldung den Empfänger nicht erreicht haben.
Der Wolf-Agents Web Security Check untersucht CSP-Header der abgerufenen Antwort. Er weist weder die Verträglichkeit aller Seiten noch sichere Nonce-Erzeugung, tatsächliche Reportzustellung oder die Abwesenheit von XSS nach. Für eine begrenzte Headerfrage kann der Befund genügen; die Rollout-Entscheidung braucht weitere Belege.
Einordnung von Nachweisen: CSP kann Risiken von Skript-Injection begrenzen. Für relevante Zahlungsskripte beschreibt PCI SSC unter anderem Autorisierung, Integrität, Inventar und Manipulationsüberwachung im Kontext von PCI DSS 4.0.1. Ein Nonce, Hash oder Header allein belegt diese Abläufe nicht und bestätigt auch keine vollständige NIS2- oder Datenschutzkonformität. PCI SSC: Sicherheit von Zahlungsseiten
Vier Phasen mit überprüfbaren Übergängen
Planen Sie nach Abdeckung und geklärten Befunden. Eine feste Zahl von Tagen oder Wochen ist kein technisches Freigabekriterium.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Phase | Aufgabe | Beleg für den nächsten Schritt |
|---|---|---|
| 1. Ausliefern | Bestehende Policies erfassen, neue Report-Only-Policy und Berichtsziel einrichten. | Tatsächliche Header der relevanten Antworten sind bekannt; eine gezielt erzeugte Meldung wurde am vorgesehenen Empfänger nachvollzogen. |
| 2. Untersuchen | Repräsentative Seiten, Browser und Nutzerabläufe prüfen; Verstöße zuordnen. | Dokumentierter Testumfang, reproduzierbare relevante Befunde und ausdrücklich ungeprüfte Abläufe. |
| 3. Anpassen | Benötigte Ressourcen passend autorisieren oder Einbindungen ändern. | Relevante Konflikte erklärt und betroffene Funktionen mit der überarbeiteten Policy erneut geprüft. |
| 4. Durchsetzen | Geprüfte Fassung im vorgesehenen Umfang aktivieren; Rückweg und Beobachtung bereithalten. | Funktionsprüfung unter Enforcement, überprüfte Auslieferung und benannte Zuständigkeit für Folgeänderungen. |
Die Tabelle beschreibt benötigte Belege. Sie berichtet keine hier ausgeführten Tests.
Phase 1: Report-Only und Berichtsziel einrichten
Erfassen Sie zunächst alle Stellen, die CSP setzen: Anwendung, Webserver, Proxy oder CDN sowie gegebenenfalls HTML-Meta-Elemente. Unterscheiden Sie die bereits durchgesetzte Basis von der neuen Testpolicy.
Das folgende Beispiel zeigt zwei HTTP-Antwortheader. Jeder Headerwert steht in einer Zeile. Die Policy ist ein Ausgangsmodell zum Erklären, keine geprüfte Produktionsvorlage. Der HTTPS-Empfänger unter example.com ist ein Platzhalter und muss von Ihnen eingerichtet werden.
Reporting-Endpoints: csp-endpoint="https://example.com/api/csp-report"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; report-uri /api/csp-report; report-to csp-endpoint'unsafe-inline' ist hier nur für Stile gesetzt. img-src erlaubt im Modell auch beliebige HTTPS-Bildquellen. Beides sind bewusste weite Freigaben, die Sie anhand Ihrer Anwendung beurteilen müssen. Die Regeln werden in diesem Modus noch nicht durchgesetzt.
report-to csp-endpoint und der gleichnamige Eintrag in Reporting-Endpoints gehören zusammen. report-uri verwendet den älteren Meldeweg. Unterstützende Browser bevorzugen report-to und ignorieren report-uri in derselben Policy. Der ältere Weg kann für Ihren Browserumfang weiter erforderlich sein; er ist als veraltet gekennzeichnet. Eine relative Endpoint-URL kann gegen die Antwort-URL aufgelöst werden. Hier macht die absolute HTTPS-Adresse das Ziel ausdrücklich sichtbar. MDN: report-to, W3C: Endpoint-Verarbeitung
Phase 2 und 3: Meldungen untersuchen und gezielt korrigieren
Verknüpfen Sie jeden relevanten Befund mit Seite, Nutzeraktion, Browser, wirksamer Direktive und Policy-Fassung. Die Browserkonsole, häufig über F12 erreichbar, ist ein Ausgangspunkt. Unter Report-Only ist eine Meldung keine Behauptung, dass die neue Policy die Aktion bereits blockiert hat.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beobachtung | Prüffrage | Mögliche Korrektur nach Klärung |
|---|---|---|
| Meldung zu einem Inline-Skript | Ist das konkrete Skript beabsichtigt, und welche Skriptdirektive greift? | Gezielter Nonce oder Hash; alternativ eine geeignete externe Einbindung. Nicht pauschal jedes Skript markieren. |
| Google Analytics oder Tag-Manager betroffen | Geht es um das Skript, eine Datenverbindung oder ein Bild? Wird die Einbindung benötigt? | Passende Direktive und erforderliche Quelle bestimmen; *.google-analytics.com und *.googletagmanager.com sind keine universelle Reparatur. |
| Google Fonts betroffen | Fehlt das Stylesheet oder die Fontdatei? | Rollen von fonts.googleapis.com in style-src und fonts.gstatic.com in font-src prüfen. Dies ist keine vollständige Anbieter-Allowlist. |
| Stripe oder PayPal betroffen | Welcher konkrete Zahlungsablauf, Frame, Skript- oder Netzwerkaufruf scheitert? | Benötigte Quellen in script-src, frame-src oder connect-src anhand der tatsächlichen Integration prüfen. Keine pauschale Freigabe aller Zahlungsdienste. |
| WebSocket betroffen | Welches wss://-Ziel und welche Verbindung werden benötigt? | Das konkrete Ziel, beispielsweise wss://socket.example.com, für connect-src beurteilen; nicht beliebige WebSocket-Ziele erlauben. |
Auch Browsererweiterungen oder nicht zur Anwendung gehörende Eingriffe können Meldungen beeinflussen. Berichte sind nicht vertrauenswürdige Eingaben. Eine gemeldete URL ist weder eine Freigabeempfehlung noch ein sicherer Beweis für einen Angriff. W3C: Grenzen von Violation Reports
Phase 4: Enforcement und Rückweg vorbereiten
Bei der Umstellung wird die geprüfte Fassung als Content-Security-Policy ausgeliefert. Das folgende Schema stellt nur den Namenswechsel dar; ... ist keine einsetzbare Policy.
Content-Security-Policy-Report-Only: ...
Content-Security-Policy: ...Prüfen Sie dabei die tatsächlichen Antworten und behalten Sie den eingerichteten Berichtsweg, soweit er für die weitere Auswertung gebraucht wird. Ein zusätzlicher Header beseitigt keine ältere Policy. Testen Sie die vorgesehenen Abläufe erneut unter Enforcement, denn erst dann greift die neue Sperre.
Halten Sie die zuletzt bekannte funktionsfähige durchgesetzte Policy als Rückweg bereit. Wenn Sie die neue Fassung vorübergehend nur noch als Report-Only ausliefern, entfällt deren Durchsetzung. Eine bereits vorhandene funktionsfähige Basis sollte dabei bestehen bleiben. Analysieren Sie den konkreten Konflikt und prüfen Sie die Korrektur vor einer erneuten Umstellung.
Mit Befunden entscheiden, nicht nach verstrichener Zeit
Die nächste Tabelle ist eine Prüfvorlage für Ihre Anwendung. Sie setzt einen unterstützenden Browser, die genannte effektive Direktive und keine zusätzliche blockierende Policy voraus. Die Teststände Ihrer Anwendung sind offen. Eine getrennte eigene lokale Probe weiter unten zeigt ausgewählte Regelwirkungen; sie nimmt Ihre Nutzerabläufe nicht vorweg.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Modellfall | Annahme und erwartete Regelwirkung | Benötigter praktischer Beleg | Teststand hier |
|---|---|---|---|
| Erfasster Standardablauf | Ein eigenes externes Skript passt zu script-src 'self'. Diese Regel würde es unter Enforcement zulassen. | Tatsächlich ausgeführter Ablauf einschließlich erwarteter Funktion, nicht nur geladene Datei. | Nicht ausgeführt. |
| Erkannter Anpassungsbedarf | Ein benötigtes Inline-Skript passt nicht zu script-src 'self'. Die Report-Only-Policy würde es nicht blockieren; dieselbe durchgesetzte Regel würde es blockieren. | Konsolenbefund und nachvollzogene Meldung, anschließend gezielte Autorisierung und erneuter Funktionstest. | Nicht ausgeführt. |
| Seltener Ablauf ohne Untersuchung | Ein Passwort-Reset-Dialog wurde noch nicht betrachtet. Sein Verhalten unter der Policy ist unbekannt. | Dialog und nachgeladene Ressourcen in den relevanten Zuständen testen. | Ungeprüft; kein Erfolg aus fehlenden Reports ableitbar. |
| Meldung nur in der Konsole | Eine lokale Violation wurde angenommen, ein eingegangener Bericht nicht. | Denselben kontrollierten Vorgang am Empfänger nachweisen und Format/Policy zuordnen. | Berichtszustellung nicht nachgewiesen. |
Diese Trennung verhindert, dass ein grüner Headerbefund einen unbekannten Nutzerablauf verdeckt. Wenn Sie Ergebnisse an eine Agentur oder einen Betreiber übergeben, dokumentieren Sie URL, Zustand, Browser/Version, Policy-Fassung, Sollverhalten, tatsächliches Ergebnis und offene Wege. Setzen Sie dabei keine echten personenbezogenen Inhalte in Beispieldatensätze.
Den Berichtsweg nachvollziehen
Eine brauchbare Gegenprobe verbindet den ausgelösten Regelverstoß mit einem tatsächlich empfangenen Bericht. Die Strecke besteht aus mehreren getrennten Schritten:
- Das Dokument erhält die beabsichtigten CSP- und Reporting-Header.
- Ein kontrollierter Vorgang verletzt eine unterstützte Regel.
- Der Browser erzeugt einen Bericht und versucht dessen Übermittlung.
- Der vorgesehene Empfänger nimmt das passende Format an und ordnet den Bericht zu.
report-uri verwendet ein JSON-Objekt mit csp-report und typischerweise application/csp-report; die Reporting API über report-to verwendet ein Array von Berichten mit application/reports+json. Der Empfänger muss die tatsächlich genutzten Formate unterscheiden. W3C: Report-Formate, MDN: report-uri
Die Reporting API liefert nach bestem Bemühen. Browser können Meldungen verzögern oder verwerfen; eine vollständige Zustellung ist nicht garantiert. Auch ein funktionierender Empfänger macht fehlende Berichte nicht zum Nachweis fehlerfreier Abläufe. W3C: Reporting-Garantien
Beschränken Sie die gespeicherten Daten auf das für die Untersuchung Nötige. Berichte können URLs und andere sensible Inhalte enthalten; behandeln Sie sie als untrusted input und geben Sie sie in Auswertungsoberflächen sicher aus. Zweck, Zugriff und Aufbewahrung müssen zu Ihrem Betrieb passen. Dieser Artikel legt keine universelle Aufbewahrungsfrist fest.
Schematische Erklärung · keine Messung
Ein Header beweist keinen Reportempfang
- Dokument und wirksame Policy
Die Antwort enthält die beabsichtigte CSP und die passenden Reporting-Header. Report-Only selbst blockiert nicht; eine gleichzeitig durchgesetzte Policy kann blockieren.
- Kontrollierter Regelverstoß im Browser
Ein tatsächlich ausgeführter Vorgang verletzt eine unterstützte Regel. Konsolenbefund und Berichtserzeugung sind lokale Beobachtungen.
- Den verwendeten Meldeweg zuordnen
Älterer Weg: report-uri
JSON-Objekt mit
csp-report, Medientypapplication/csp-report.Neuerer Weg: report-to
Benannter Eintrag in
Reporting-Endpoints. Array von Berichten, Medientypapplication/reports+json.Unterstützt der Browser
report-to, ignoriert erreport-uriderselben Policy. Die Zweige sind keine Zusage doppelter Zustellung. - Übermittlungsversuch
Ein erzeugter Bericht kann verspätet eintreffen oder ausbleiben. Die Reporting API garantiert keine vollständige oder sofortige Zustellung.
- Eigener eingerichteter Empfänger
Erst der tatsächliche Eingang im passenden Format, zugeordnet zu Dokument, Regelverstoß und Policy-Fassung, belegt den Empfang.
Ablaufmodell: Jeder Übergang braucht seinen eigenen Beleg. Ein empfangener Bericht sagt nichts über bisher ungeprüfte Nutzerabläufe aus. Wolf-Agents stellt hier keinen Reportingdienst bereit.
Zeitplanung als Organisationshilfe
Ein Plan über sechs Wochen kann bei der Organisation helfen. Er ist weder Mindestdauer noch Nachweis einer erfolgreichen Einführung. Bei jedem Übergang zählen die tatsächlichen Belege.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beispielzeitraum | Arbeit | Zu dokumentieren |
|---|---|---|
| Woche 1 | Report-Only und Empfänger anschließen | Ausgelieferte Fassung und nachvollzogener Bericht. |
| Woche 2 | Login, Checkout, Administration und Passwort-Reset erfassen, soweit vorhanden | Geprüfte Zustände, Browser und noch fehlende Abläufe. |
| Woche 3 | Policy und Einbindungen anpassen | Ursache jedes relevanten Konflikts und Ergebnis der erneuten Prüfung. |
| Woche 4 | Vorgesehene Fassung festlegen | Abgedeckte Funktionen und ausdrücklich verbleibende Grenzen. |
| Woche 5 | Im freigegebenen Umfang durchsetzen | Funktionsergebnis unter Enforcement und verfügbarer Rückweg. |
| Woche 6 und danach | Änderungen begleiten und Befunde auswerten | Zuständigkeit, Anlass und passender Turnus für Folgeprüfungen. |
48 Stunden ohne Meldung oder sieben Tage ohne neue Verstoßart ersetzen diese Belege nicht. Seltene Funktionen können trotz langer Beobachtung unberührt bleiben.
Nach der Einführung weiterpflegen
Neue Funktionen, Drittanbieter und Bibliotheksänderungen können andere Ressourcen benötigen. Untersuchen Sie geänderte Regeln bei Bedarf in einer parallelen Report-Only-Policy; eine funktionierende durchgesetzte Basis bleibt dabei erhalten. Prüfen Sie außerdem, ob bisherige Wildcards oder Quellen noch benötigt werden.
Sie können beispielsweise monatliche Berichtssichten und vierteljährliche Policy-Prüfungen vorsehen, wenn das zu Ihrem Betrieb passt. Das sind Organisationsbeispiele, keine allgemeine Mindestfrequenz. Kritische Funktionsänderungen brauchen ihre Prüfung zum Änderungszeitpunkt, nicht erst beim nächsten Kalendertermin.
Eigene Funktionsprobe und vorhandener Reporting-Nachweis
Am 29. September 2026 wurden synthetische Dokumente auf einem eigenen Loopback-Server seriell mit Playwright-Chromium 147.0.7727.15, Firefox 148.0.2 und Playwright-WebKit 26.4 geprüft. Der Funktionsvergleich verwendete die folgende Report-Only-Policy und einen eigenen Empfänger unter /reports:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'; report-uri /reportsDas lokale Dokument enthielt ein eigenes externes Skript und ein direktes Inline-Skript ohne Freigabe. Für Enforcement wurde derselbe Policy-Wert im Header Content-Security-Policy ausgeliefert; ein dritter Fall lieferte beide Header gleichzeitig. Der Ausschnitt richtet keinen Empfänger ein und ist keine universelle Policy für Ihre Website.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Ausgelieferte Policy | Eigenes externes Skript | Inline-Skript ohne Freigabe | Separater Berichtsnachweis |
|---|---|---|---|
| Nur Report-Only | Ausgeführt. | Ausgeführt; Verstoß mit Disposition report. | Browserereignis und tatsächlicher POST am eigenen Collector. |
| Durchgesetzt | Ausgeführt. | Blockiert; Verstoß mit Disposition enforce. | Browserereignis und tatsächlicher POST am eigenen Collector. |
| Report-Only und durchgesetzt parallel | Ausgeführt. | Durch die wirksame Enforcement-Policy blockiert. | Berichtseingang zusätzlich zur Funktionsbeobachtung geprüft. |
Diese Probe nutzte allein report-uri: empfangen wurde jeweils ein JSON-Objekt mit csp-report und application/csp-report. Das ist kein moderner Reporting-API-Bericht und keine Zusage einer Zustellzeit. Die Nonce-Probe ergänzt den anschließenden positiven Fall gezielter Skriptautorisierung.
Moderner Bericht: eng begrenzten vorhandenen Nachweis nutzen
Für report-to und Reporting-Endpoints liegt eine getrennte eigene Probe vom 28. September 2026 vor: Chrome 153.0.8010.54, headless, jeweils mit frischem normalem Wegwerfprofil und privatem Kontext. Ein eigener HTTPS-Collector empfing tatsächlich application/reports+json mit einem Array und Berichtstyp csp-violation. Die Details ordnet das Reporting-API-Kapitel ein.
Beide Läufe verwendeten --short-reporting-delay und beobachteten jeden Fall 35 Sekunden; --disable-background-networking war aus den Playwright-Startvorgaben ausgenommen. Für TLS galt nur eine SPKI-Ausnahme für das eigene Wegwerfzertifikat. Es gab keine globale Zertifikatsausnahme und keine Änderung am System-Truststore. Die beschleunigte Diagnose belegt keine normale Zustelllatenz, keinen Firefox-/WebKit-Gleichstand und keinen beliebigen fremden Collector. Bei absichtlich falsch zugeordnetem Endpointnamen kam innerhalb des Beobachtungsfensters weder ein moderner Bericht noch ein Legacy-Fallback an.
Prüfgrenze: Das sind isolierte Funktions- und Transportbelege mit synthetischen Inhalten. Reale Anmeldung, Checkout, Passwort-Reset, Erweiterungen, Gateways und Ihre gesamte Browserpopulation wurden damit nicht geprüft. Übernehmen Sie das Vorgehen aus Inventar, Empfangsgegenprobe, Funktionstest und bewusstem Rückweg.
Passende Vertiefungen
Für einen ersten Befund zur öffentlich erreichbaren Konfiguration können Sie den Web Security Check öffnen. Der ausgewiesene Messumfang gilt auch dann, wenn Sie bereits eine Rollout-Checkliste erstellt haben.
Häufige Fragen
Wie lange sollte die Report-Only-Phase dauern?
Eine feste Mindestdauer beweist keine Ausrollreife. Testen Sie repräsentative Browser, Seiten und Abläufe einschließlich seltener Funktionen und prüfen Sie den Reportempfang. Geklärte relevante Verstöße und erfolgreiche Funktionstests erlauben eine Aussage über den tatsächlich untersuchten Umfang.
Was mache ich, wenn die Seite unter Enforcement nicht funktioniert?
Stellen Sie möglichst die zuletzt bekannte funktionsfähige durchgesetzte Policy wieder her. Wenn Sie die neue Fassung vorübergehend nur als Report-Only untersuchen, entfällt deren Durchsetzung. Bewahren Sie eine vorhandene funktionsfähige Basis, klären Sie den Verstoß und prüfen Sie die Korrektur vor dem nächsten Wechsel.
Kann ich verschiedene Policies für verschiedene Seiten verwenden?
Ja, wenn Ihre Auslieferung die passenden Header je Antwort setzen kann. Richten Sie die Policy an den benötigten Funktionen aus. Ein Admin-Bereich braucht nicht automatisch eine lockerere Policy; Inline-Skripte können gezielt autorisiert werden. Prüfen Sie Pfade, Antwortzustände und das Zusammenspiel mit weiteren Headern.
Sollte ich Reporting nach der Umstellung deaktivieren?
Die weitere Auswertung kann Änderungen und neue Konflikte sichtbar machen. Behalten Sie sie bei, soweit sie einen klaren betrieblichen Zweck erfüllt, und legen Sie Zuständigkeit und Turnus fest. Reporting ist kein vollständiger Angriffsnachweis und kein Ersatz für Funktionstests; Datenumfang und Aufbewahrung bleiben eigenständige Entscheidungen.
Primärquellenprüfung am 29. September 2026, einschließlich des CSP-3-Arbeitsentwurfs vom 16. September 2026 und der Reporting-Spezifikation. Eigene lokale Probe und wiederverwendeter Chrome-Reporting-Nachweis sind oben getrennt beschrieben. Wolf-Agents bietet über diese Anleitung keinen Reporting- oder Monitoringdienst an.