Content Security Policy und Consent in TYPO3 13

Kurz: Eine Content Security Policy (CSP) legt fest, von wo eine Seite Skripte, Styles, Bilder und Einbettungen laden darf – eingeschleuster Code läuft dann nicht mehr. TYPO3 13 bringt sie mit: im Backend immer aktiv, im Frontend per Schalter. Wer sie einschaltet, findet schnell alle Stellen mit Inline-Skripten, in eigenen Templates, in Extensions, im Consent-Banner. Bewährt hat sich: erst nur melden lassen, dann erzwingen; fremde Dienste vollständig in die Domainliste, eigene Skripte mit Nonce; Tracking und Einbettungen erst nach der Einwilligung laden – und beim Widerruf wieder entfernen.

Was TYPO3 13 mitbringt

• Im Backend ist die CSP seit TYPO3 13.0 immer aktiv. Backend-Module von Extensions, die noch mit Inline-JavaScript arbeiten, fallen beim Upgrade von 12 auf 13 deshalb auf.
• Im Frontend schalten Sie sie ein, mit dem Feature-Schalter security.frontend.enforceContentSecurityPolicy – oder zunächst nur mit security.frontend.reportContentSecurityPolicy: Dann meldet der Browser Verstöße, blockiert aber nichts.
• Je Site eine eigene Richtlinie in config/sites/<site>/csp.yaml, aufbauend auf der Voreinstellung von TYPO3 (inheritDefault: true) und mit Änderungen (mutations) für die eigenen Quellen.
• Ein Backend-Modul für Verstöße. Unter Admin Tools → Content Security Policy sammelt TYPO3 die gemeldeten Verstöße und schlägt Lösungen vor.

Erst melden, dann erzwingen

Die Reihenfolge, die sich in unseren Projekten bewährt hat:

1. Bestandsaufnahme: Welche Skripte, Schriften, Tracker und Einbettungen lädt die Seite, und von wo?
2. Nur melden lassen, einige Wochen lang, auf Staging und Live. Die Berichte können statt ins TYPO3-Backend auch an einen eigenen Dienst gehen; in drei unserer Projekte laufen sie in Sentry auf. Die Adresse dafür steht in $GLOBALS['TYPO3_CONF_VARS']['FE']['contentSecurityPolicyReportingUrl'].
3. Beheben: Nonces in die Templates, Inline-Handler wie onclick durch Skriptdateien ersetzen, fehlende Quellen in die csp.yaml.
4. Erzwingen – und die Berichte weiter beobachten, denn jede neue Einbettung kann einen neuen Verstoß bringen.

Ein Hinweis zum Backend-Modul: Lösungsvorschläge lassen sich dort per Klick übernehmen, über die Oberfläche aber nicht wieder entfernen. Tragen Sie Freigaben besser von Hand in die csp.yaml ein – dann stehen alle Regeln an einer Stelle und im Git.

Google-Dienste vollständig freigeben

Welche fremden Quellen eine Seite laden darf, steht in der csp.yaml als Liste von Domains. Bei Google-Diensten wird sie lang: Nutzt eine Seite Google Analytics mit den Werbefunktionen von Google Ads, lädt sie je nach Land von google.de, google.at, google.ch und so weiter – und die CSP erlaubt keine Platzhalter am Ende eines Hostnamens. Jede Länderdomain muss einzeln hinein. In einem unserer Projekte stehen deshalb 188 Google-Domains in der Richtlinie, über alle Direktiven zusammen mehr als 400 Einträge.

Google führt die nötigen Domains in seiner CSP-Anleitung auf und rät, die Einträge für die Werbefunktionen gleich beim ersten Einrichten aufzunehmen. Dann muss die Richtlinie nicht geändert werden, wenn später jemand Google Ads verknüpft. So gehen wir auch vor. Für Ihre Entwickler, in der csp.yaml:

inheritDefault: true
mutations:
  - mode: extend
    directive: 'img-src'
    sources:
      - "https://*.google-analytics.com"
      - "https://*.googletagmanager.com"
      - "https://*.google.de"
      - "https://*.google.com"
      # … und die übrigen Länderdomains aus der Anleitung von Google

Eigene Skripte, die TYPO3 ausliefert, bekommen dagegen einen Nonce: einen Zufallswert, den TYPO3 für jede Antwort neu erzeugt. In Fluid-Templates geschieht das über useNonce:

<f:asset.script identifier="main" src="EXT:sitepackage/Resources/Public/JavaScript/main.js" useNonce="1" />

Wo es in unseren Projekten hakte

• Das Standard-JavaScript von TYPO3. In einem Projekt blockierte die CSP das mitgelieferte default_frontend.js, das unter anderem verschlüsselte E-Mail-Links auflöst. Abhilfe: config.removeDefaultJS = 1 und die Datei selbst als Asset mit useNonce="1" einbinden.
• Extensions ohne Nonce. Der Spamschutz von wsm/form-spamshield lädt sein Prüfskript ohne Nonce. Unter erzwungener CSP luden manche Browser es nicht – und ohne dieses Skript funktioniert der Spamschutz nicht. Abhilfe: das Partial der Extension im eigenen Sitepackage überschreiben und useNonce="1" ergänzen. Rechnen Sie bei jeder Extension mit Frontend-JavaScript damit.
• Consent-Banner mit Inline-Styles. Cookiebot setzt seine Styles inline, das Projekt erlaubt deshalb 'unsafe-inline' für Styles. Das ist ein vertretbarer Kompromiss, solange er auf Styles beschränkt bleibt und nicht auf Skripte übergreift.

Einwilligung: mehr als ein Banner

Nicht notwendige Cookies und Zugriffe auf das Endgerät brauchen nach § 25 TDDDG eine Einwilligung. Für die Technik heißt das:

• Erst nach der Einwilligung laden. Tracking, Videos, Karten und externe Schriften lädt die Seite erst, wenn der Besucher zugestimmt hat. Bis dahin zeigt sie einen Platzhalter. Die CSP muss die Quellen trotzdem kennen, auch die für Vorschaubilder, etwa bei YouTube.
• Beim Widerruf aufräumen. Viele Consent-Lösungen laden nach einem Widerruf nur nichts Neues mehr – die schon gesetzten Cookies und Einträge im Local Storage bleiben. Prüfen Sie, dass sie gelöscht werden, für Google Analytics etwa die Cookies _ga und _ga_….
• Den Gültigkeitsbereich nicht nachträglich ändern. Ein Cookie ist über Name, Domain und Pfad bestimmt. Stellt man die Einwilligung nachträglich auf Subdomains um, schreibt die Consent-Lösung ein zweites Cookie mit anderer Domain, das alte bleibt. Bei wiederkehrenden Besuchern liegen dann zwei Einwilligungen im Browser, und geänderte Einstellungen scheinen nicht zu greifen. In einem Projekt mit sgalinski/sg-cookie-optin haben wir das per Patch gelöst, der die alten Varianten vor dem Schreiben entfernt.
• Google Consent Mode v2. Wer Google Ads oder Google Analytics für Besucher aus dem EWR nutzt, muss Google seit März 2024 mitteilen, wozu eingewilligt wurde – mit den Signalen ad_user_data und ad_personalization zusätzlich zu ad_storage und analytics_storage. Zertifizierte Consent-Tools setzen sie selbst; bei einem eigenen Banner gehört das in die Integration.

Ob ein Banner rechtlich genügt, beurteilen Ihr Datenschutzbeauftragter oder Ihre Rechtsberatung. Die Technik muss nur dafür sorgen, dass vor der Einwilligung wirklich nichts lädt.

Prüfen Sie selbst

• Browser-Konsole: Meldungen mit „Content Security Policy“ zeigen blockierte Quellen.
• Netzwerk-Tab vor der Einwilligung: Es dürfen keine Anfragen an Google, YouTube oder andere Dritte laufen.
• Nach einem Widerruf: In den Entwicklerwerkzeugen unter „Speicher“ nachsehen, ob die Tracking-Cookies verschwunden sind.

Eine CSP gehört für uns zur Härtung jeder Installation, zusammen mit den übrigen Security-Headern – mehr dazu auf unserer Seite zum TYPO3 Hosting. Oder schreiben Sie uns über das Formular unten.

Stand: 24.9.2026 · Quellen: TYPO3 Explained: Content Security Policy, TYPO3: Modul Content Security Policy, Google Tag Platform: CSP, Google Tag Platform: Consent Mode, Google Ads: Consent Mode im EWR