Show Menu
THEMEN×

Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)

Das Hauptziel von Content Security Policy (CSP) besteht darin, Cross-Site Scripting (XSS) zu verhindern. Bei Cross-Site Scripting wird der Browser dazu gebracht, schädliche Inhalte auszuführen, die scheinbar aus vertrauenswürdigen Quellen stammen. In Wahrheit stammen sie jedoch von einer anderen Quelle. Mit CSP kann der Browser (im Namen des Benutzers) überprüfen, ob das Skript tatsächlich von einer vertrauenswürdigen Quelle stammt.
CSP wird implementiert, indem Sie Ihren Serverantworten den Content-Security-Policy -HTTP-Header hinzufügen. Weitere Informationen zur CSP finden Sie auf der Seite des Mozilla Developer Network: https://developer.mozilla.org/de-DE/docs/Web/HTTP/CSP

Voraussetzungen für CSP

Tag-Management-Systeme sind für das dynamische Laden von Skripten ausgelegt. CSP blockiert diese dynamisch geladenen Skripte, da sie Sicherheitsprobleme verursachen können.
Wenn Sie möchten, dass Launch mit Ihrem CSP zusammenarbeitet, müssen Sie sicherstellen, dass zwei Bedingungen erfüllt sind:
  • Die Quelle für Ihre Launch-Bibliothek muss als vertrauenswürdig eingestuft werden. Wenn diese Bedingung nicht erfüllt ist, werden die Launch-Bibliothek und andere erforderliche JavaScript-Dateien vom Browser blockiert und nicht auf der Seite geladen.
  • Inline-Skripte müssen erlaubt sein. Wenn diese Bedingung nicht erfüllt ist, werden auf Regeln von benutzerspezifischem Code basierende Aktionen auf der Seite blockiert und nicht ordnungsgemäß ausgeführt.
Wenn Sie Launch verwenden möchten und ein CSP vorhanden ist, müssen Sie beide Voraussetzungen schaffen, ohne andere Skripte fälschlicherweise als sicher zu kennzeichnen. Die Erhöhung der Sicherheit erfordert somit einen höheren Arbeitsaufwand auf Ihrer Seite.

Vertrauenswürdige Quellen

Wenn Sie Ihre Bibliothek selbst hosten, ist die Quelle für Ihre Bibliothek wahrscheinlich Ihre eigene Domäne. Um die Host-Domäne als sichere Quelle festzulegen, gehen Sie folgendermaßen vor:
script-src 'self'
Wenn Sie die Bibliothek von Adobe gehostet wird (mit dem „Managed by Adobe“-Host), befindet sich Ihre Bibliothek auf assets.adobedtm.com. In diesem Fall sollte Ihre Bibliothek in etwa folgendermaßen aussehen:
script-src 'self' assets.adobedtm.com
Sie sollten self als sichere Domäne spezifizieren, damit Sie keine Skripte beschädigen, die bereits geladen werden. Zusätzlich muss assets.adobedtm.com als sicher angegeben werden, da ansonsten Ihre Launch-Bibliothek nicht auf der Seite geladen wird.
Weitere Informationen zu vertrauenswürdigen Quellen finden Sie auf der Seite des Mozilla Developer Network .

Inline-Skripte

Inline-Skripte stellen eine Herausforderung für CSP dar, da sie standardmäßig nicht zulässig sind. Sie haben zwei Optionen, um Inline-Skripte zuzulassen:
  • Alle Inline-Skripte zulassen (am wenigsten sicher)
  • Mit Nonce zulassen (gute Sicherheit)
Die CSP-Spezifikation enthält auch Informationen zu einer dritten Option mit Hashes. Dieser Ansatz ist aber aus einer Reihe von Gründen, von denen einige sehr kompliziert sind, nicht mit einem Tag-Management-System verwendbar.

Gute Sicherheit – Nonces

Bei dieser Methode wird eine Nonce generiert und zu Ihrem CSP und zu jedem Inline-Skript hinzugefügt. Wenn der Browser die Anweisung erhält, ein Inline-Skript mit einer darin enthaltenen Nonce zu laden, wird der Nonce-Wert mit dem im CSP-Header enthaltenen Wert verglichen. Wenn diese übereinstimmen, wird das Skript geladen.
Die Nonce sollte bei jedem Laden einer neuen Seite verändert werden.
Es gibt eine sehr wichtige Voraussetzung: Sie müssen die Launch-Bibliothek asynchron laden. Dies funktioniert nicht mit dem synchronen Ladevorgang der Launch-Bibliothek, da Konsolenfehler auftreten und Regeln nicht ordnungsgemäß ausgeführt werden.
Im obigen Beispiel können Sie die Nonce folgendermaßen zur Adobe-gehosteten CSP hinzufügen:
script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'
Danach müssen Sie Launch mitteilen, wo die Nonce zu finden ist. Launch verwendet sie beim Laden von Inline-Skripten. Damit Launch die Nonce beim Laden eines Skripts verwendet, gehen Sie folgendermaßen vor:
  1. Erstellen Sie ein Datenelement, das Ihre Nonce referenziert (je nachdem wo Sie sie auf Ihrer Datenschicht platzieren).
  2. Konfigurieren Sie die Haupterweiterung und spezifizieren Sie, welches Datenelement Sie verwendet haben.
  3. Veröffentlichen Sie das Datenelement und die Änderungen in der Haupterweiterung.
Ein weiterer Hinweis: Dies betrifft nur das Laden von benutzerdefiniertem Code. Was mit dem benutzerdefinierten Code ausgeführt wird, ist davon nicht betroffen. Sie können auch benutzerdefinierten Code schreiben, der nicht mit Ihrer CSP übereinstimmt. In diesem Fall hat die CSP Vorrang. Wenn Sie beispielsweise benutzerdefinierten Code zum Laden von Inline-Skripten verwenden, indem Sie ihn am DOM anhängen, kann ihn Launch nicht finden oder die Nonce korrekt anfügen. Mancher benutzerdefinierter Code funktioniert deshalb nicht wie erwartet.

Geringe Sicherheit – Inline zulassen

Wenn die obige Option bei Ihnen nicht anwendbar ist, können Sie Ihre CSP anweisen, alle Inline-Skripte zuzulassen. Dies ist zwar die am wenigsten sichere Option, sie ist aber am einfachsten zu implementieren und zu warten.
Wenn also Adobe das Hosting verwaltet und Sie die Domäne assets.adobedtm.com als vertrauenswürdige Quelle kennzeichnen, würde Ihre CSP in etwa folgendermaßen aussehen:
script-src 'self' assets.adobedtm.com 'unsafe-inline'
Weitere Informationen zum Zulassen von Inline-Skripten finden Sie auf der MDN-Site unter https://developer.mozilla.org/de-DE/docs/Web/HTTP/Headers/Content-Security-Policy/script-src .