So führen Sie eine Content Security Policy ein, bevor Leser defekte Seiten melden

Beginnen Sie die Einführung einer Content Security Policy mit Beobachtung und einer repräsentativen Seitenauswahl. Eine kopierte Richtlinie kann die Startseite sicher erscheinen lassen und zugleich Medien, Bezahlung oder redaktionelle Vorschau beschädigen. Ziel ist eine Richtlinie, die unerwünschte Ausführung einschränkt und die tatsächlich beabsichtigten Funktionen erhält.

Die CSP-Spezifikation unterscheidet eine durchgesetzte Richtlinie von Content-Security-Policy-Report-Only. Letztere lässt den Browser einen Vorschlag beobachten, ohne ihn durchzusetzen. Damit lernen Sie dessen Auswirkungen kennen. Der Modus bietet nicht den Schutz einer durchgesetzten Fassung und schaltet keine bereits separat durchgesetzte Richtlinie aus.

Erfassen Sie die tatsächlich betriebene Website

Listen Sie repräsentative Seitentypen und Abläufe vor dem Schreiben der Regeln auf. Dazu gehören normale Artikel, Medienseiten, Suche, Übersetzungen und tatsächlich vorhandene kommerzielle Funktionen. Ergänzen Sie keine erfundenen Dienste. Eine statische Publikation ohne Konten, Tracking oder Zahlungsskripte hat andere Abhängigkeiten als ein Mitgliedschaftsgeschäft.

Ermitteln Sie für jeden Ablauf benötigte Skripte, Stile, Bilder, Schriften, Frames und Verbindungen. Notieren Sie Verantwortliche und Zweck externer Abhängigkeiten. Ein im Browser sichtbarer Hostname ist ein Hinweis, keine automatische Vertrauensfreigabe für alles, was er ausliefert. Fragen Sie vor einer Ausnahme, ob die Funktion überhaupt auf die Seite gehört.

Prüfen Sie tatsächliche Antwortheader und Auslieferungswege. Eine Richtlinie kann am Ursprung, beim Hosting oder in einer Auslieferungsschicht entstehen. Tragen mehrere Stellen Header bei, bestimmen Sie vor Änderungen die maßgebliche Konfiguration. Sonst verändert die Entwicklung eine lokale Einstellung, während Leser weiterhin eine andere Richtlinie erhalten.

Liefern Sie den Vorschlag als Report-only-Header aus

Laut Spezifikation wird die Report-only-Richtlinie in einem Meta-Element nicht unterstützt. Richten Sie den HTTP-Antwortheader über den vorgesehenen Bereitstellungsprozess ein. Behalten Sie die bestehende durchgesetzte Richtlinie im Blick. Die Beobachtung eines zusätzlichen Vorschlags beweist nicht, dass sämtliche bisherigen Einschränkungen aufgehoben wurden.

Wählen Sie ein unterstütztes Meldeverfahren und bestätigen Sie, dass der empfangende Endpunkt die erwarteten Meldungen annimmt. Die MDN-Headerreferenz erläutert Auslieferung und Meldekonfiguration. Eine Meldedirektive allein erstellt keinen Dienst, der Daten empfängt, speichert und auswertet.

Begrenzen Sie den ersten Versuch auf einen nachvollziehbaren Umfang. Nutzen Sie eine kontrollierte Umgebung oder eine passende begrenzte Einführung und bewahren Sie die vorige Konfiguration auf. Prüfen Sie Browserkonsole und Erfassungsweg. Kommen keine Meldungen an, untersuchen Sie zuerst die Erfassung, bevor Sie den Vorschlag für verletzungsfrei halten.

Behandeln Sie Meldungen als nicht vertrauenswürdige Eingaben. Begrenzen Sie unnötige Speicherung, schützen Sie den Sammler und verteilen Sie sensible Seitenadressen nicht in großen Vorfallskanälen. Eine Meldung kann Betriebsinformationen zum Seitenkontext eines Besuchers enthalten. Prüfen Sie vor einem externen Meldedienst, welche Daten die gewählte Einrichtung erfasst, statt sie als neutralen Transportweg anzusehen.

Machen Sie aus Meldungen Entscheidungen statt immer mehr Freigaben

Gruppieren Sie Befunde nach Seitentyp, Direktive und Ressource. Reproduzieren Sie typische Fehler anhand der vorgesehenen Abläufe. Browsererweiterungen oder ungewöhnliche Zustände können Störmeldungen erzeugen. Eine Meldung sollte deshalb eine Prüfung auslösen, nicht automatisch eine neue Quelle freigeben. Umgekehrt kann pauschales Abtun unerwarteter Einträge echte Integrationsfehler verdecken.

Entscheiden Sie für jede legitime Abhängigkeit, ob sie bleibt, ersetzt oder entfernt wird. Eine wachsende Liste weiter Ausnahmen kann sämtliche alten Skripte erhalten und den Richtlinienzweck schwächen. Die CSP-Hinweise von OWASP erläutern auch stärkere Ansätze mit Nonces oder Hashes. Dafür sind korrekte Erzeugung und Auslieferung nötig, kein wiederverwendeter fester Beispielwert.

Achten Sie bei Nonces besonders auf Vorschau, Lokalisierung und Cache-Verhalten. Header und erlaubtes Markup müssen zur selben Antwortanordnung gehören. Nutzen Sie die Cache-Regelprüfung, wenn eine Auslieferungsschicht verändert, was Leser erhalten. Ein erfolgreicher ungecachter Entwickleraufruf repräsentiert nicht automatisch die gecachte öffentliche Seite.

Setzen Sie kontrolliert durch und beobachten Sie weiter

Definieren Sie Abnahmekriterien über Funktionen, nicht nur über ruhige Meldeströme. Können Leser Artikel öffnen, vorgesehene Medien abspielen und echte Bezahlvorgänge abschließen? Funktioniert die Vorschau? Sind relevante Sprachen, Bildschirmgrößen und Einwilligungszustände geprüft? Die Erfassung kann unvollständig sein. Keine aufgezeichneten Verstöße beweisen daher nicht, dass alle Wege getestet wurden.

Dokumentieren Sie vor der Durchsetzung Richtlinienversion, Testfälle, Grenzen und genauen Rückkehrweg. Nutzen Sie einen Staging- und Rollback-Ablauf. Ändern Sie die durchgesetzte Richtlinie im regulären Releaseprozess und prüfen Sie anschließend ausgelieferte Header und dieselben Abläufe am Live-Ergebnis. Halten Sie während der ersten Beobachtung eine zuständige Betreuung verfügbar.

Prüfen Sie nach der Änderung Fehlermeldungen zusammen mit Funktionsnachweisen. Fällt eine kritische legitime Funktion aus, stellen Sie eine bekannte funktionierende Konfiguration wieder her oder korrigieren Sie gezielt. Erlauben Sie nicht pauschal alle Quellen, nur um Warnungen abzustellen. Die Reparatur sollte auf die betroffene Abhängigkeit und das erforderliche Verhalten zurückführbar sein.

Führen Sie Abhängigkeitsinventar und Richtlinienprüfung bei künftigen Releases fort. Das Entfernen eines Anbieters sollte überflüssige Freigaben entfernen; eine neue Funktion eine Kompatibilitätsprüfung auslösen. CSP wirkt am besten als gepflegter Teil der Auslieferung neben Anwendungssicherheit und Zugriffskontrolle, nicht als einmal durch einen Header erworbenes Abzeichen.