Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)

Eine Content Security Policy (CSP) ist eine Sicherheitsfunktion, die Cross-Site-Scripting-Angriffe (XSS) verhindert. 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 CSPs kann der Browser (im Namen des Benutzers) überprüfen, ob das Skript tatsächlich von einer vertrauenswürdigen Quelle stammt.

CSPs werden implementiert, indem Sie Ihren Server-Antworten einen Content-Security-Policy-HTTP-Header hinzufügen oder indem Sie ein konfiguriertes <meta>-Element im <head>-Abschnitt Ihrer HTML-Dateien hinzufügen.

Hinweis

Weitere Informationen zu CSP finden Sie in den MDN-Webdocs.

Adobe Experience Platform Launch ist ein Tag-Management-System, das Skripte dynamisch auf Ihrer Website lädt. Eine Standard-CSP blockiert diese dynamisch geladenen Skripte aufgrund potenzieller Sicherheitsprobleme. Dieses Dokument enthält Anleitungen zum Konfigurieren des CSP, um dynamisch geladene Skripten aus Platform Launch zu ermöglichen.

Wenn Sie möchten, dass Adobe Experience Platform Launch mit Ihrem CSP zusammenarbeitet, müssen Sie sicherstellen, dass zwei Bedingungen erfüllt sind:

  • Die Quelle für Ihre Platform Launch-Bibliothek muss als vertrauenswürdig eingestuft werden. Wenn diese Bedingung nicht erfüllt ist, werden die Platform 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 Platform 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.

Wenn Sie Platform Launch verwenden möchten und ein CSP vorhanden ist, müssen Sie beide Voraussetzungen schaffen, ohne andere Skripte fälschlicherweise als sicher zu kennzeichnen. Der Rest dieses Dokuments enthält Anleitungen, wie Sie dies erreichen können.

Hinzufügen von Platform Launch als vertrauenswürdige Quelle

Bei Verwendung eines CSP müssen Sie alle vertrauenswürdigen Domains in den Wert der Content-Security-Policy-Kopfzeile einschließen. Der Wert, den Sie für Platform Launch angeben müssen, hängt vom verwendeten Hosting-Typ ab.

Selbstständiges Hosting

Wenn Sie Ihre Bibliothek selbst hosten, ist die Quelle für Ihre Bibliothek wahrscheinlich Ihre eigene Domain. Mit der folgenden Konfiguration können Sie festlegen, dass die Host-Domain eine sichere Quelle ist:

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 Platform Launch-Bibliothek nicht auf der Seite geladen wird.

HTTP-Header

Content-Security-Policy: script-src 'self'

HTML <meta>-Tag

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

Adobe-verwaltetes Hosting

Wenn Sie einen von Adobe verwalteten Host verwenden, wird Ihr Build auf assets.adobedtm.com aufbewahrt. In diesem Fall sollten Sie die folgende Konfiguration verwenden:

HTTP-Header

Content-Security-Policy: script-src 'self' assets.adobedtm.com

HTML <meta>-Tag

Es gibt eine sehr wichtige Voraussetzung: Sie müssen die Platform Launch-Bibliothek asynchron laden. Dies funktioniert nicht mit dem synchronen Ladevorgang der Platform Launch-Bibliothek, da Konsolenfehler auftreten und Regeln nicht ordnungsgemäß ausgeführt werden.

<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com">

Sie sollten self als sichere Domain spezifizieren, damit Sie keine Skripte beschädigen, sie bereits geladen werden. Zusätzlich muss assets.adobedtm.com als sicher angegeben werden, da ansonsten Ihr Bibliotheks-Build nicht auf der Seite geladen wird.

Inline-Skripte

CSP deaktiviert Inline-Skripte standardmäßig und muss daher manuell konfiguriert werden, um sie zuzulassen. Sie haben zwei Optionen, um Inline-Skripte zuzulassen:

Hinweis

Die CSP-Spezifikation enthält Details zu einer dritten Option mit Hashes, aber dieser Ansatz ist nicht möglich, wenn Tag-Management-Systeme wie Platform Launch verwendet werden. Weitere Informationen zu den Einschränkungen bei der Verwendung von Hashes in Platform Launch finden Sie im Handbuch Subresource Integrity (SRI).

Mit Nonce zulassen

Bei dieser Methode wird eine kryptografische Nonce erzeugt und zu Ihrem CSP und jedem Inline-Skript auf Ihrer Website hinzugefügt. Wenn der Browser die Anweisung erhält, ein Inline-Skript mit einer darin enthaltenen Nonce zu laden, vergleicht der Browser den Nonce-Wert mit dem im CSP-Header enthaltenen Wert. Wenn diese übereinstimmen, wird das Skript geladen. Die Nonce sollte bei jedem Laden einer neuen Seite verändert werden.

WICHTIG

Um diese Methode verwenden zu können, müssen Sie den Build asynchron laden. Dies funktioniert nicht, wenn der Build synchron geladen wird, was zu Konsolenfehlern und nicht ordnungsgemäß ausgeführten Regeln führt. Weitere Informationen finden Sie im Handbuch zur asynchronen Implementierung.

Die folgenden Beispiele zeigen, wie Sie Ihre Nonce zur CSP-Konfiguration für einen von Adobe verwalteten Host hinzufügen können. Wenn Sie Self-Hosting verwenden, können Sie assets.adobedtm.com ausschließen.

HTTP-Header

Content-Security-Policy: script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'

HTML <meta>-Tag

<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'">

Nachdem Sie den Header oder das HTML-Tag konfiguriert haben, müssen Sie Platform Launch mitteilen, wo die Nonce beim Laden eines Inline-Skripts zu finden ist. Damit Platform Launch die Nonce beim Laden eines Skripts verwendet, gehen Sie folgendermaßen vor:

  1. Erstellen Sie ein Datenelement, das auf die Position der Nonce in Ihrer Datenschicht verweist.
  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.
Hinweis

Der obige Prozess behandelt nur das Laden Ihres benutzerspezifischen Codes, nicht aber was dieser benutzerspezifische Code tut. Wenn ein Inline-Skript benutzerdefinierten Code enthält, der nicht mit Ihrem CSP konform ist, hat das CSP Vorrang. Wenn Sie beispielsweise benutzerdefinierten Code zum Laden von Inline-Skripten verwenden, indem Sie ihn am DOM anhängen, kann ihn Platform Launch nicht finden oder die Nonce korrekt anfügen. Dieser benutzerdefinierte Code funktioniert deshalb nicht wie erwartet.

Alle Inline-Skripte zulassen

Wenn die Verwendung einer Nonce bei Ihnen nicht anwendbar ist, können Sie Ihre CSP so konfigurieren, dass alle Inline-Skripte zugelassen werden. Dies ist zwar die am wenigsten sichere Option, sie ist aber am einfachsten zu implementieren und zu warten.

Die folgenden Beispiele zeigen, wie Sie alle Inline-Skripte im CSP-Header zulassen können.

Selbstständiges Hosting

Verwenden Sie die folgenden Konfigurationen, wenn Sie Self-Hosting verwenden:

HTTP-Header

Content-Security-Policy: script-src 'self' 'unsafe-inline'

HTML <meta>-Tag

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline'">

Adobe-verwaltetes Hosting

Verwenden Sie die folgenden Konfigurationen, wenn Sie Adobe-verwaltetes Hosting verwenden:

HTTP-Header

Content-Security-Policy: script-src 'self' assets.adobedtm.com 'unsafe-inline'

HTML <meta>-Tag

<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com 'unsafe-inline'">

Nächste Schritte

Durch Lesen dieses Dokuments sollten Sie jetzt verstehen, wie Sie Ihren CSP-Header so konfigurieren können, dass die Platform Launch-Bibliotheksdatei und Inline-Skripte akzeptiert werden.

Als zusätzliche Sicherheitsmaßnahme können Sie auch Subresource Integrity (SRI) verwenden, um abgerufene Bibliotheks-Builds zu validieren. Diese Funktion weist jedoch einige wesentliche Einschränkungen auf, wenn sie mit Tag-Management-Systemen wie Platform Launch verwendet wird. Weitere Informationen finden Sie im Handbuch zur SRI-Kompatibilität in Platform Launch.

Auf dieser Seite