CSP mit Report-Only einführen: ein praktischer Ablauf

In einer Testumgebung beginnen

Sichern Sie die aktuellen Antwortheader und die Proxy-Konfiguration. Listen Sie die Origins für Anmeldung, Zahlungen, CAPTCHA, Schriftarten und Analyse auf. Behalten Sie die bereits durchgesetzte CSP bei: Eine Beobachtungsrichtlinie ersetzt oder lockert sie nicht. Planen Sie eine Rücknahme, bevor Sie den Header ändern.

Eine Testrichtlinie in Nginx ergänzen

Platzieren Sie diese Direktive im passenden server- oder location-Block der Testwebsite. Sie ist ein restriktives Beobachtungsbeispiel, keine fertige Produktionsrichtlinie. Sie erlaubt Quellen derselben Origin und meldet Inline-Skripte sowie externe Quellen, blockiert sie aber nicht selbst.

Der Parameter always schließt Fehlerantworten ein. In Nginx 1.26.3 verhindert add_header in einer verschachtelten location die Vererbung übergeordneter add_header-Direktiven. Bewahren Sie bestehende Sicherheitsheader und prüfen Sie jede betroffene Route. Fügen Sie nicht blind eine zweite Kopie eines Headers hinzu, den bereits die Anwendung liefert.

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;

Eine echte Antwort und das Browserverhalten prüfen

Führen Sie vor dem Neuladen des Dienstes nginx -t für Ihre Installation aus. Öffnen Sie die Testseite mit den Entwicklertools: Prüfen Sie, ob die Antwort Content-Security-Policy-Report-Only enthält, und beobachten Sie die Konsole bei der Nutzung. Dieses Beispiel dient zur Beobachtung im Browser und richtet keine serverseitige Berichtssammlung ein.

Zum Sammeln benötigen Sie einen funktionierenden HTTPS-Endpunkt sowie Reporting-Endpoints zusammen mit report-to. Das ältere report-uri hat eine andere Datensemantik und Kompatibilität. Begrenzen Sie die Datenmenge und die Aufbewahrung: Berichts-URLs können Nutzerdaten enthalten. Senden Sie keine Berichte an eine Beispieladresse.

Einen kontrollierten Vorher-nachher-Test verwenden

Unser isolierter Test verwendet ein externes Skript derselben Origin und ein Inline-Skript. Mit diesem Report-Only-Header laufen beide; der Inline-Verstoß wird gemeldet. Wird dieselbe Richtlinie über Content-Security-Policy durchgesetzt, läuft das externe Skript, während das Inline-Skript blockiert wird. Testen Sie Ihre eigenen Seiten: Dieses Beispiel zertifiziert keine Drittanbieterintegrationen.

Erlauben Sie jede erforderliche Quelle bewusst. Verwenden Sie für notwendigen Inline-Code von der Anwendung erzeugte Nonces oder geprüfte Hashes statt weitreichender unsafe-inline-Freigaben. Eine Nonce muss unvorhersehbar sein und für jede Antwort neu erzeugt werden; ein kopierter fester Wert ist keine Lösung.

Schrittweise durchsetzen und die Rücknahme prüfen

Wenn repräsentative Nutzerabläufe funktionieren, übertragen Sie die geprüfte Richtlinie zunächst in der Testumgebung in den durchgesetzten Header. Prüfen Sie Anmeldung, Wiederherstellung, Bezahlung, Einbettungen und Fehlerseiten erneut. Mehrere durchgesetzte Richtlinien kombinieren Einschränkungen; ein neuer Header kann einen bestehenden nicht lockern. Stellen Sie die gesicherte Konfiguration wieder her, wenn benötigte Abläufe ausfallen.

check.uk.app untersucht zurückgegebene Header und führt die Anwendung nicht aus, um die CSP-Abdeckung zu prüfen. Testumgebung: Nginx 1.26.3 und Chromium-basierter Microsoft Edge, 26. September 2026. Für dieses Beispiel wurde keine Produktions-CSP geändert.