Die Website bekommt eine strengere Sicherheitsregel. Kurz darauf bleiben Bilder leer, das Buchungsformular lädt nicht und der Warenkorb reagiert nicht mehr. Die Regel arbeitet möglicherweise genau so, wie sie geschrieben wurde. Nur passt sie noch nicht zur Website. Eine Content Security Policy ist kein Textbaustein, den man irgendwo kopiert und anschließend vergisst.

Eine CSP legt fest, welche Ressourcen und bestimmte Verhaltensweisen der Browser zulassen soll. Sie kann ein wichtiger Schutzbaustein sein. Damit sie nützt, muss sie zur tatsächlichen Anwendung passen und kontrolliert eingeführt werden. Für Website-Betreiber ist dabei weniger wichtig, jede Direktive auswendig zu kennen. Wichtig ist, die richtigen Fragen an die Entwicklung zu stellen und eine vernünftige Abnahme zu vereinbaren.

Was soll eine CSP auf Ihrer Website leisten?

Die MDN-Referenz zur Content Security Policy beschreibt, wie der Browser über Richtlinien erlaubte Quellen und Verhaltensweisen steuern kann. Eine Policy kann beispielsweise festlegen, von welchen Quellen Skripte oder Bilder geladen werden dürfen. Sie ersetzt weder sichere Anwendungslogik noch das Schließen von Schwachstellen, kann aber die Möglichkeiten bestimmter Angriffe einschränken.

Beginnen Sie deshalb mit einem konkreten Ziel. Soll eine bisher sehr offene Regel enger werden? Fehlt die CSP vollständig? Gibt es bekannte Ausnahmen, die überprüft werden sollen? Ein Satz wie „Wir möchten nur die tatsächlich benötigten Skriptquellen erlauben“ ist für die Planung hilfreicher als „Wir möchten eine bessere Note“. Die Bewertung eines Scanners ist eine Rückmeldung, nicht die fachliche Zielbeschreibung Ihrer Anwendung.

Vor der Regel kommt die Bestandsaufnahme

Sammeln Sie die Funktionen, die Ihre Website wirklich benötigt: eigene Skripte, eingebettete Medien, Formulare, Bezahldienste, Schriften und weitere Schnittstellen. Prüfen Sie unterschiedliche Seitentypen und Besucherzustände. Die Startseite allein enthält möglicherweise weder den Checkout noch das Bewerbungsformular. Eine aus ihrem Netzwerkprotokoll abgeleitete Freigabeliste kann deshalb an anderer Stelle unvollständig sein.

Hinterfragen Sie gleichzeitig alte Einbindungen. Eine ungenutzte Marketingquelle muss nicht aus Gewohnheit in die neue Regel übernommen werden. Jede Ausnahme sollte einen benannten Zweck haben. Halten Sie fest, zu welcher Funktion sie gehört und wer sie betreut. Diese Zuordnung spart später Zeit, wenn ein Dienst seinen Hostnamen ändert oder ein Plugin zusätzliche Quellen anfordert.

Erst beobachten, dann durchsetzen

Mit Content-Security-Policy-Report-Only lässt sich eine Richtlinie zunächst beobachtend einsetzen: Verstöße können gemeldet werden, ohne dass diese beobachtende Richtlinie die betreffenden Ressourcen selbst blockiert. Das ist eine Möglichkeit, Auswirkungen vor einer verbindlichen Durchsetzung zu untersuchen. Eine bereits zusätzlich aktive CSP kann weiterhin blockieren.

Vereinbaren Sie mit der Entwicklung, wo die Beobachtungen ankommen und wer sie auswertet. Nicht jede Meldung verlangt eine zusätzliche Freigabe. Manche Einträge stammen aus Browsererweiterungen oder unerwarteten Fremdeinflüssen. Andere zeigen eine echte benötigte Funktion. Auch die empfangenen Meldedaten und ihre Aufbewahrung sollten bewusst eingerichtet werden. Ein Sammelpunkt ohne Zuständigkeit ist noch kein kontrollierter Testbetrieb.

Ausnahmen verständlich begründen lassen

Eine sehr breite Freigabe kann eine Fehlermeldung verschwinden lassen, ohne das ursprüngliche Schutzziel sinnvoll zu erreichen. Fragen Sie deshalb bei Änderungen: Welche Funktion benötigt diese Ausnahme? Warum reicht keine engere Einstellung? Kann die zugrunde liegende Einbindung angepasst werden? Sie müssen die technische Lösung nicht selbst entwerfen, sollten aber ihren Zweck verstehen können.

Das gilt besonders für Einstellungen, die Inline-Code oder dynamische Codeausführung betreffen. Einzelne Schlüsselwörter sollten im Zusammenhang der gesamten Policy bewertet werden. Ein automatisierter Hinweis ist dabei ein Prüfauftrag, kein vollständiges Urteil über die Sicherheit Ihrer Website. Lassen Sie sich die verbleibenden Kompromisse dokumentieren. Das ist ehrlicher und für den späteren Betrieb nützlicher als eine pauschale Aussage „Jetzt ist alles sicher“.

Die Abnahme gehört an die wichtigen Kundenwege

Prüfen Sie vor und nach der Durchsetzung dieselben Abläufe: Navigation, Suche, Formulare, Buchung und gegebenenfalls Bestellung. Nehmen Sie mobile Ansichten, verschiedene Sprachen und relevante Consent-Zustände dazu. Die Policy kann auf einer einfachen Inhaltsseite unauffällig sein und in einem eingebetteten Werkzeug eine wichtige Verbindung verhindern. Dort ist die Funktionskontrolle besonders wertvoll.

Legen Sie einen Rückfallplan fest, bevor Sie die Regel produktiv verschärfen. Wer kann bei einer Störung reagieren? Welche zuvor geprüfte Konfiguration steht bereit? Wie wird eine vorübergehende Ausnahme wieder überprüft? Vermeiden Sie eine dauerhafte Notlösung, die nach dem ersten Alarm niemand mehr anfasst. Im Beitrag zur Website-Abnahme mit der Agentur finden Sie weitere Fragen für eine nachvollziehbare Übergabe.

Eine CSP bleibt Teil der laufenden Website-Pflege

Neue Plugins, Zahlungsanbieter oder eingebettete Dienste können Änderungen an der Richtlinie nötig machen. Verbinden Sie diese Anpassungen mit Ihrer normalen Änderungsdokumentation. Ein neues Werkzeug wird dann nicht nur optisch eingebaut, sondern auch mit seinen technischen Abhängigkeiten erfasst. Die bestehende Policy sollte nicht bei jedem Funktionswunsch reflexartig weiter geöffnet werden.

Ein regelmäßiger Technik-Check kann auf fehlende oder auffällige Header aufmerksam machen. Die passende Konfiguration und ihre Wirkung bleiben Aufgaben der betreuenden Entwicklung. Der Beitrag Security-Header prüfen erklärt den größeren Zusammenhang. Eine gute CSP ist am Ende weder die längste noch die strengste Zeichenfolge. Sie ist eine begründete, getestete Schutzregel für die Website, die Ihre Besucher tatsächlich benutzen.