Eine Content-Security-Policy einführen, ohne Ihre Website zu beschädigen

Ein Sicherheitsscan, ein Lighthouse-Bericht oder Ihr Hoster meldet, dass die Website keine Content-Security-Policy hat. Die Lösung sieht nach einem einzigen Header aus. Eine Policy aus einem Blog kopieren, ausrollen, fertig. Dann lädt das Buchungsformular nicht mehr, das Chat-Widget verschwindet oder, schlimmer, sichtbar geht nichts kaputt und Ihre Google Ads zählen keine Conversions mehr. Wir hätten das auf unserer eigenen Website fast genauso gemacht.

Die kurze Antwort: Beginnen Sie mit Content-Security-Policy-Report-Only, nicht mit dem echten Header. Er meldet, was die Policy blockieren würde, ohne zu blockieren. Sammeln Sie diese Berichte mindestens eine Woche lang von echten Besuchern, auf jedem Seitentyp, ergänzen Sie, was legitim ist, und schalten Sie erst dann auf Durchsetzung um.

Was eine Content-Security-Policy tut

Sie ist ein HTTP-Header, der dem Browser sagt, von welchen Quellen eine Seite Skripte, Stile, Bilder, Schriften, Frames und Verbindungen laden darf. Gelingt es einem Angreifer, ein Skript einzuschleusen (über ein gehacktes Plugin, ein kompromittiertes Drittanbieter-Skript oder ein Formular, das Eingaben nicht bereinigt), weigert sich der Browser, es auszuführen oder Daten an einen unbekannten Server zu senden. Sie ist eine der stärksten Abwehrmaßnahmen gegen Cross-Site-Scripting und Kartenskimmer im Checkout.

Dass keine vorhanden ist, kommt häufig vor. Als wir vor dem Black Friday 1.482 Onlineshops gescannt haben, wurde etwa ein Drittel wegen einer fehlenden Content-Security-Policy markiert.

Warum „einfach den Header hinzufügen“ Websites kaputt macht

Eine Policy ist eine Whitelist. Alles, was Sie vergessen, wird blockiert, für den Besucher unbemerkt, mit nur einer Zeile in der Browser-Konsole. Die üblichen Opfer:

Analytics- und Werbe-Tags. Google Analytics, Google Ads, Meta Pixel und Microsoft Clarity laden von mehreren Hosts und leiten oft zu weiteren weiter.
Einbettungen. Buchungstools (Calendly), Karten, YouTube, Chat-Widgets und Zahlungs-iframes brauchen jeweils eigene Frame- und Skriptquellen.
Inline-Skripte. Viele Frameworks und CMS legen kleine Skripte direkt in die Seite. Eine strikte Policy blockiert sie, es sei denn, Sie erlauben 'unsafe-inline' oder fügen eine Nonce hinzu (einen Zufallswert pro Seitenaufruf).
Seiten, die niemand testet. Die Kontaktseite, die Danke-Seite nach einem Formular, der Checkout. Gerade dort laden oft die Conversion- und Zahlungsskripte.

Was auf unserer eigenen Website passiert ist

Unsere Website läuft seit Juli 2026 mit einer Report-Only-Policy. Die erste Version haben wir aus einem vollständigen Netzwerk-Trace der Produktion gebaut, nicht aus einer Vermutung. Das haben dieser Trace und die Berichte erfasst. Jeder dieser Punkte hätte etwas kaputt gemacht, wenn wir am ersten Tag durchgesetzt hätten:

Der Google-Ads-Conversion-Ping feuert nur auf der Kontaktseite. Eine Prüfung der Startseite sieht ihn nie. Eine Durchsetzung ohne ihn hätte dazu geführt, dass Ads unsere wichtigste Conversion nicht mehr zählt: eine Kontaktanfrage.
Microsoft Clarity leitet zu einem Bing-Host weiter. *.clarity.ms zu erlauben reicht nicht; die ID-Synchronisierung springt zu c.bing.com.
Der Ads-Remarketing-Pixel nutzt die Länderdomain des Besuchers, etwa google.be oder google.co.th, nicht google.com. Dafür gibt es in der CSP keinen Platzhalter. Wir listen daher die Länder, in denen wir verkaufen, und nehmen für den Rest eine kleine Lücke in den Zielgruppendaten in Kauf.
Auf jeder Seite tauchte ein zweiter Ads-Host auf. Am 19. Oktober 2026 zeigte ein neuer Durchlauf über sechs Seitentypen, dass pagead2.googlesyndication.com überall lud. Er war nicht im Trace vom Juli. Unser eigener Sicherheitsscan hatte gesagt, die Policy sehe gut aus und wir könnten den Header „einfach umbenennen“. Hätten wir das getan, wären die Ads-Conversions ohne einen einzigen sichtbaren Fehler auf null gefallen.

Zwei kleinere Erkenntnisse aus derselben Arbeit. Chrome ignoriert upgrade-insecure-requests in einer Report-Only-Policy und schreibt dazu einen Konsolenfehler, den Lighthouse Ihnen dann ankreidet. Fügen Sie diese Direktive also erst beim Umschalten auf Durchsetzung hinzu. Außerdem schreibt unser Framework (SvelteKit) ein Inline-Hydration-Skript, während unser Hosting nur feste Header erlaubt. Deshalb bleibt 'unsafe-inline' bei Skripten bestehen, bis wir Nonces pro Anfrage einführen. Eine Policy mit einem bekannten, dokumentierten Kompromiss blockiert immer noch weit mehr als gar keine Policy.

So führen Sie eine CSP ein, ohne etwas zu beschädigen

Listen Sie auf, was Ihre Seiten laden. Öffnen Sie die Entwicklertools des Browsers, Tab Network, und klicken Sie durch Startseite, eine Inhaltsseite, die Kontakt- oder Buchungsseite, den Checkout und die Danke-Seite. Notieren Sie jeden Host.
Schreiben Sie die Policy anhand dieser Liste. Beginnen Sie mit default-src 'self' und fügen Sie jeden Host zu der Direktive hinzu, die er braucht: script-src, connect-src, img-src, frame-src, style-src, font-src.
Rollen Sie sie als Report-Only mit Berichten aus. Senden Sie sie als Content-Security-Policy-Report-Only mit sowohl report-to (plus einem Reporting-Endpoints-Header) als auch dem älteren report-uri. Nicht jeder Browser unterstützt report-to schon, also nutzen Sie beide. Protokollieren Sie nur die Direktive, den blockierten Host und den Seitenpfad: Vollständige URLs können Besucherdaten enthalten.
Lesen Sie die Berichte eine Woche lang. Echte Besucher nutzen andere Browser, Erweiterungen, Länder und Seiten als Sie. Ergänzen Sie, was Ihnen oder Ihren Tools gehört; ignorieren Sie das Rauschen von Browser-Erweiterungen.
Prüfen Sie nach jeder Tag-Änderung erneut. Marketing-Tools wechseln ihre Hosts, ohne es anzukündigen. Gehen Sie nach jeder Änderung an Tags oder Policy dieselben Seitentypen noch einmal durch.
Schalten Sie auf Durchsetzung um. Benennen Sie den Header in Content-Security-Policy um, behalten Sie die Berichte bei und beobachten Sie in den folgenden Tagen die Berichte und Ihre Conversion-Zahlen.

Ihre Situation	Was zu tun ist
Scan meldet „keine CSP“, Website funktioniert einwandfrei	Starten Sie diese Woche mit Report-Only; kopieren Sie keine Policy von anderswo
Sie haben eine CSP hinzugefügt und etwas funktioniert nicht mehr	Stellen Sie den Header jetzt zurück auf Report-Only und korrigieren Sie die Policy anhand der Konsolenfehler
Sie schalten Google Ads oder Meta-Werbung	Testen Sie die Seiten, auf denen Conversions auslösen, und prüfen Sie die Conversion-Zahlen einige Tage nach der Durchsetzung
Onlineshop mit Checkout	Testen Sie eine echte Zahlung (im Testmodus) mit aktiver Policy; Zahlungs-iframes brauchen eigene Quellen
WordPress mit vielen Plugins	Rechnen Sie mit einer langen Liste; Plugins, die Inline-Skripte einschleusen, erzwingen vorerst eventuell `'unsafe-inline'`

Brauchen Sie Hilfe?

Wir richten eine Content-Security-Policy auf sichere Weise ein: ein Trace Ihrer echten Seiten, eine Report-Only-Phase mit Protokollierung und der Wechsel zur Durchsetzung, sobald die Berichte sauber sind. Ihre Analytics und Conversions prüfen wir davor und danach. Senden Sie uns Ihre Website-Adresse →

Sie führen eine Agentur? Wir übernehmen das unter Ihrem Namen, unter NDA. So arbeiten wir mit Agenturen →

Häufige Fragen

Was ist Content-Security-Policy-Report-Only?

Eine Variante des CSP-Headers, die nur meldet, was die Policy blockieren würde, ohne es zu blockieren. Browser senden die Verstöße an die von Ihnen festgelegte Berichtsadresse, sodass Sie die Policy korrigieren können, bevor Sie sie durchsetzen.

Wie lange sollte eine CSP im Report-Only-Modus bleiben?

Mindestens eine Woche mit echtem Traffic, ohne dass legitime Quellen in den Berichten übrig sind. Länger, wenn Ihre Website Seiten mit wenigen Besuchern hat, etwa einen Checkout oder eine Danke-Seite.

Sollte ich report-to oder report-uri verwenden?

Beides. report-to ist die neuere Variante und braucht einen Reporting-Endpoints-Header; report-uri ist veraltet, wird aber noch gebraucht, weil nicht jeder Browser report-to unterstützt.

Kann eine CSP das Tracking von Google Ads oder Analytics kaputt machen?

Ja. Fehlen die Hosts, von denen die Tags laden oder an die sie Daten senden, blockiert der Browser sie ohne sichtbaren Fehler, und Conversions werden einfach nicht mehr gezählt.

Ist eine CSP mit 'unsafe-inline' nutzlos?

Nein. Sie schränkt weiterhin ein, woher Skripte, Frames und Verbindungen kommen dürfen und wohin Daten gesendet werden. 'unsafe-inline' durch Nonces zu ersetzen ist besser, aber ein dokumentierter Kompromiss ist besser als gar keine Policy.