Chat-Widget bei strenger Content-Security-Policy: Rahmen, Prüfsumme, Freigaben

Vor dem Weihnachtsgeschäft wird es auf vielen Websites still: Ab einem Stichtag gehen keine Änderungen mehr live, und was bis dahin nicht sitzt, bleibt bis ins neue Jahr liegen. In den Wochen davor ziehen viele Betriebe deshalb ihre Sicherheits-Header fest, allen voran die Content-Security-Policy. Ein eingebettetes Chatfenster ist dabei ein typischer Konfliktfall: Es bringt Skript auf die Seite, öffnet einen Rahmen und spricht mit einem Server. Dieser Beitrag zeigt, was ein Widget einer Richtlinie abverlangen kann, welche zwei Einträge Ihre Richtlinie nach der Beschreibung auf der Integrationsseite für den XICBOT-Lader und sein Chatfenster braucht und welche Direktiven unberührt bleiben, wie der Rahmen abgeschottet und die Auslieferung über Prüfsummen abgesichert ist, wie Sie festlegen, welche Seiten den Assistenten laden dürfen, und was die Einbindung nicht mitbringt.

Grafik vergrößern

Beschriftungen der Abbildung

• Ihre Seite: Content-Security-Policy
• script-src
• Quelle des Laders zulassen
• connect-src
• für den Lader nicht nötig
• style-src
• kein Stylesheet eingehängt
• img-src
• Marke aus Elementen, kein Bild
• frame-src
• Adresse des Rahmens zulassen
• nach dem Laden
• Rahmen mit eigenem Ursprung
• sandbox mit genau einer Erlaubnis: Skripte
• Ursprung meldet sich als null
• allow-same-origin fehlt mit Absicht
• mit Skripten zusammen hebt es den Sandkasten auf
• Beide Teile mit Prüfsumme und crossorigin
• Schnipsel ohne Prüfsumme: Einstiegsname wechselt
• Nachrichten tragen Befehle, keinen Verlauf
• Startangaben im Adressfragment, ohne Server
• Gegenrichtung: welche Seiten laden dürfen (Domainliste je Assistent)
• Wirt auf der Liste
• Widget lädt
• Wirt nicht auf der Liste
• Widget lädt nicht
• Liste leer
• jeder Wirt ist erlaubt

Strenge Inhaltsrichtlinie und Chatfenster: wer was braucht

Warum Sicherheits-Header vor der Saison angefasst werden

Ein Code-Freeze vor dem Weihnachtsgeschäft hat einen einfachen Grund: In den umsatzstärksten Wochen soll keine Änderung die Seite gefährden. Daraus folgt eine zweite Regel, die seltener ausgesprochen wird: Was an der Auslieferung noch angefasst werden soll, wird vorher angefasst. Kopfzeilen wie die Content-Security-Policy gehören dazu, weil sie das Verhalten jeder Seite auf einmal ändern. Eine Richtlinie, die im November zu eng gesetzt wird, kann einen Bezahlschritt, ein Formular oder ein eingebettetes Chatfenster lahmlegen, ohne dass es im eigenen Test auffällt. Eine Richtlinie, die zu weit bleibt, schützt dagegen kaum. Für die Frage, wie eng sie sein sollte, gibt es einen nüchternen Bezugspunkt: das IT-Grundschutz-Kompendium des Bundesamts für Sicherheit in der Informationstechnik. Im Baustein für Webanwendungen und Webservices heißt es in der Anforderung APP.3.1.A21:

Unmittelbar nach der Liste steht der Satz, um den es bei einem Chatfenster geht: „Die verwendeten HTTP-Header SOLLTEN so restriktiv wie möglich sein.“ Die Anforderung gehört im Baustein zu den Standard-Anforderungen. Über sie sagt das Kompendium, dass sie gemeinsam mit den Basis-Anforderungen dem Stand der Technik für diesen Baustein entsprechen und grundsätzlich erfüllt werden sollten. So restriktiv wie möglich heißt für eine Content-Security-Policy: Jede Quelle, die eine Seite laden darf, steht einzeln in der Richtlinie, und jede Ausnahme hat einen Grund. Ein Widget, das man einbaut, ohne zu wissen, was es lädt, verträgt sich damit schlecht. Ein Widget, dessen Bedarf dokumentiert ist, lässt sich dagegen Zeile für Zeile einordnen.

Was ein Chatfenster einer Richtlinie typischerweise abverlangt

Eine Content-Security-Policy ist eine Liste von Direktiven, und jede regelt eine Art von Ressource: Skripte, Rahmen, Verbindungen, Stile, Bilder. Ein eingebettetes Chatfenster berührt je nach Bauart mehrere davon zugleich, weil es aus mehreren Teilen besteht: einer Skriptzeile in Ihrer Vorlage, einem sichtbaren Auslöser, einem Fenster, das häufig in einem Rahmen läuft, und einer Verbindung zu einem Server, der die Antworten liefert. Die Tabelle beschreibt allgemein, wofür ein Widget eine Direktive typischerweise braucht. Sie beschreibt kein bestimmtes Produkt; welche Zeilen bei einem konkreten Widget zutreffen, steht im besten Fall in dessen Dokumentation.

Der Konflikt entsteht selten aus böser Absicht, sondern aus Bequemlichkeit. Steht in der Dokumentation eines Widgets nur der Hinweis, die Richtlinie sei anzupassen, wird im Zweifel großzügig freigegeben: ein Platzhalter für alle Unterdomänen, unsafe-inline für Stile, Verbindungen zu jeder Adresse. Jede dieser Ausnahmen gilt dann nicht nur für das Chatfenster, sondern für alles, was auf der Seite läuft. Eine Richtlinie wird so schrittweise weiter, ohne dass jemand das beschlossen hätte. Angriffe über Inhalte, die ein Assistent liest, sind ein eigenes Thema, das der Beitrag zu Prompt Injection behandelt. Hier geht es um die Einbettung selbst.

Was der XICBOT-Lader nicht braucht

Für XICBOT beschreibt die Seite zur Integration, welche Direktiven Ihre Richtlinie für das Ladeskript nicht aufweichen muss, und nennt zu jeder den Grund aus dem Quelltext. Eingebaut wird ein einzelnes Skript-Element mit dem Merkmal defer und dem öffentlichen Schlüssel Ihres Assistenten. Das Ladeskript ist eine einzelne Datei ohne Abhängigkeit; es öffnet auf Ihrer Seite eine Hülle mit einem offenen Schatten-DOM, zeichnet darin den Auslöser und hängt erst nach dem vollständigen Laden Ihrer Seite das Chatfenster ein. Die Eigenschaften der Hülle werden einzeln am Element gesetzt, damit Ihre Richtlinie nichts blockieren muss. Drei Direktiven bleiben damit unberührt:

• Kein connect-src auf die Schnittstelle: Der Lader ruft selbst nichts über das Netz ab, der Verkehr beginnt erst im Rahmen.
• Kein style-src: Es wird kein Stylesheet und kein Style-Element eingehängt, und Zuweisungen am Element fallen nicht unter diese Direktive.
• Kein img-src für die Marke: Die Marke im Auslöser besteht aus Elementen, nicht aus einem Bild.
• Ein hinterlegtes Auslöserbild kommt als Datenadresse und nicht über das Netz; SVG wird dort abgewiesen, weil SVG Skript tragen kann.

Was auf Ihrer Seite läuft, bleibt damit überschaubar. In unserer eigenen Messung lag das Ladeskript auf Ihrer Seite, komprimiert, bei 24,1 KB (eigene Messung der ausgelieferten Dateien). Gemessen wurde nur die Datei, die auf der fremden Seite läuft, mit der Kompression, die der Webserver tatsächlich schickt; das Chatfenster liegt im eigenen Rahmen und ist in dieser Zahl nicht enthalten. Was das für die Ladezeit bedeutet, beschreibt der Beitrag zu Chat-Widget und Ladezeit; die Messung selbst steht unter Messreihen.

Zwei Auslieferungswege, ein eigener Ursprung

Ausgeliefert wird das Ladeskript auf einem von zwei Wegen: über die Widgetdomain oder über einen Pfad auf Ihrer eigenen Domain, den Sie einrichten. Der Lader bestimmt seine Basis aus dem Verzeichnis, aus dem er selbst geladen wurde; liegt diese Basis auf Ihrer Domain, läuft auch die Schnittstelle darunter. Für die Richtlinie Ihrer Seite ist der Unterschied greifbar: Beim Weg über die Widgetdomain steht im Netzwerkprotokoll des Besuchers neben Ihrer Adresse die Widgetadresse, beim eigenen Pfad nur Ihre Adresse. Das Chatfenster bringt in beiden Fällen eine eigene Richtlinie mit; die beiden Kopfzeilen dafür setzt entweder der Rand am Widgetursprung oder Ihr Server auf Ihrem Pfad.

Entscheidend ist die letzte Zeile. First-party heißt hier zweierlei, und die beiden Ebenen werden gern verwechselt: Die Auslieferung können Sie auf Ihre Domain holen, das Chatfenster läuft trotzdem in einem eigenen Ursprung, denn genau dort liegt die Trennung zwischen Ihrer Seite und dem Gespräch. Welcher Weg zu Ihnen passt, hängt vor allem daran, wer Ihren Server betreut. Wie die Einbindung insgesamt abläuft, beschreibt der Beitrag KI-Assistent sauber in Website und Shop einbinden; wo die Daten danach verarbeitet werden, steht unter Datenschutz und Hosting.

Der Rahmen als Schranke: eine Erlaubnis, nicht zwei

Ein Rahmen mit dem Attribut sandbox startet mit allen Einschränkungen: Sein Inhalt gilt als Inhalt eines eigenen, undurchsichtigen Ursprungs, Skripte, Formulare und eine Reihe weiterer Schnittstellen sind abgeschaltet. Jede Erlaubnis, die im Attribut steht, hebt eine dieser Einschränkungen wieder auf. Das XICBOT-Chatfenster läuft in einem Rahmen mit genau einer Erlaubnis: Skripte. Die Erlaubnis auf denselben Ursprung, allow-same-origin, fehlt mit Absicht. Der Ursprung des Rahmens meldet sich deshalb als null, und die Trennung wirkt in beide Richtungen: Ihre Seite kann das Fenster nicht lesen und das Fenster nicht Ihre Seite. Warum gerade diese zweite Erlaubnis fehlt, steht als Warnung in der HTML-Spezifikation:

Der Satz beschreibt genau den Fall, der beim Weg über Ihren eigenen Pfad entsteht: Rahmen und Seite haben dann denselben Ursprung. Mit beiden Erlaubnissen wäre der Sandkasten in diesem Fall wirkungslos. Ohne die zweite bleibt der Rahmen ein eigener, undurchsichtiger Ursprung, auch wenn er von Ihrer Domain geladen wird. Die Funktionsübersicht hält das in einem Satz fest: Das Chatfenster läuft in einem eigenen Ursprung ohne allow-same-origin. Für die Arbeit an Richtlinie und Vorlage folgt daraus eine Regel, die sich aufzuschreiben lohnt: Wer den Rahmen später anfasst, nimmt die Erlaubnis auf denselben Ursprung nicht dazu, auch nicht, um ein Darstellungsproblem schnell zu lösen. Was zwischen Seite und Fenster trotzdem ausgetauscht wird und was davon auf Ihrer Seite bleibt:

• Zwischen Seite und Fenster läuft ein Nachrichtenprotokoll mit Befehlen und Kennungen, ohne Gesprächsverlauf. Formularwerte aus dem Gespräch gehen erst nach Bestätigung durch den Besucher an Ihre Seite.
• Die Gesprächskennung legt der Lader mit Frist im Speicher Ihrer Seite ab. Wer sie kennt, kann den Verlauf abrufen; mehr dazu unten bei den Grenzen.
• Der Rahmen gibt keine Verweisadresse nach außen.
• Die Startangaben liegen im Adressfragment; ein Fragment wird nicht an einen Server übertragen und steht in keinem Zugriffsprotokoll.
• Geometriemeldungen aus dem Fenster prüft der Lader feldweise erneut, weil der Weg dazwischen über eine fremde Seite führt.
• Von Ihrer Seite liest der Lader genau drei Werte ab, Schriftart, Eckenradius und Markenfarbe; erben kann der Rahmen nichts.

Prüfsummen: wo sie sitzen und wo bewusst nicht

Eine Prüfsumme im Attribut integrity sagt dem Browser, welchen Inhalt er für eine Datei erwartet. Stimmt die gelieferte Datei nicht überein, wird sie verworfen. Die Spezifikation dazu, Subresource Integrity, liegt beim W3C als Arbeitsentwurf vom 20. März 2026 vor und beschreibt die Folge eines Fehlschlags so:

Bei XICBOT tragen die beiden Teile, die der Rahmen nachlädt, eine solche Prüfsumme, dazu Fassungsnamen aus ihrem Inhalt und die Angabe crossorigin, dass sie fremden Ursprungs geladen werden. Diese Angabe ist Pflicht und kein Beiwerk: Ohne sie wäre die Antwort undurchsichtig, und die Prüfung schlüge fehl. Unter einem Fassungsnamen liegt kein anderer Inhalt als der, aus dem der Name entstanden ist; ein unbekannter Fassungsname ergibt einen Fehler und keine stille Ersatzlieferung. Ein Fassungsname wird ein Jahr zwischengespeichert, der Einstiegsname fünf Minuten, die Rahmenhülle gar nicht.

Zur Auslieferung gehören außerdem die Kopfzeilen der Widget-Dateien: Zwischenspeicherangaben, eine offene Herkunftsfreigabe und eine ausdrückliche Ressourcenfreigabe für fremde Ursprünge. Nach jedem Ausrollen läuft ein Rauchtest, der diese Kopfzeilen zählt, statt sie nur anzusehen, und der prüft, ob die Fassungsdateien im Rahmen ihre Prüfsumme tragen. Für Ihre Vorlage heißt das: Die Zeile wird einmal eingesetzt und danach nicht wieder angefasst, auch wenn eine neue Fassung des Widgets ausgeliefert wird. Wie ein Fassungswechsel am Assistenten selbst abläuft, beschreibt der Beitrag zur Aktualisierung ohne Ausfall.

Die Gegenrichtung: welche Seiten laden dürfen

Eine Content-Security-Policy schützt Ihre Seite vor dem, was sie lädt. Die umgekehrte Frage stellt sie nicht: Wer darf Ihren Assistenten auf seiner Seite einbinden? Der öffentliche Schlüssel steht im Quelltext jeder Seite, die das Widget lädt, und lässt sich kopieren. Dafür gibt es bei XICBOT die Domainliste je Assistent. Sie entscheidet, welche Wirte laden dürfen; auf einer Seite, die dort nicht steht, lädt das Widget nicht. Die Liste wird in der Anwendung gepflegt und nicht in einer Webserverkonfiguration, weil sie je Konto und Assistent verschieden ist. Läuft etwa eine Karriereseite auf einer eigenen Domain, gehört diese Domain beim zuständigen Assistenten auf die Liste; wie sich Assistenten in einem Konto aufteilen lassen, beschreibt der Beitrag zu mehreren Assistenten in einem Konto.

Einführen ohne Ausfall: erst berichten, dann sperren

Eine strengere Richtlinie wird am sichersten nicht auf einen Schlag scharf geschaltet. Dafür gibt es eine zweite Kopfzeile, Content-Security-Policy-Report-Only. Sie setzt die Richtlinie nicht durch, sondern meldet nur, was sie blockiert hätte, in der Konsole des Browsers und auf Wunsch an eine Berichtsadresse. Die Spezifikation Content Security Policy Level 3, beim W3C ein Arbeitsentwurf vom 16. September 2026, beschreibt diesen Weg ausdrücklich:

• Die geplante Richtlinie als Content-Security-Policy-Report-Only auf einer Testumgebung setzen, auf der das Widget eingebaut ist und deren Domain auf der Domainliste steht. Als meta-Element wird diese Kopfzeile nicht unterstützt, sie gehört in die Antwort des Servers.
• Die Seite laden, den Auslöser drücken, ein Gespräch führen und dabei die Konsole lesen: Gemeldete Verletzungen nennen in der Regel die Direktive und die blockierte Adresse.
• Gemeldete Verletzungen einzeln entscheiden: die Adresse gezielt freigeben oder die Ursache beseitigen, statt die Direktive pauschal zu öffnen.
• In der App beim Assistenten im Abschnitt „Chatfenster auf Ihrer Website“ unter „Einbindung auf Ihrer Website“ nachsehen, ob das Widget auf dem Testwirt geladen hat; dort stehen Zeitpunkt und Seite des letzten Ladens.
• Erst danach dieselbe Richtlinie als Content-Security-Policy scharf schalten und den Durchlauf auf der Live-Seite wiederholen.

Der Abschnitt „Chatfenster auf Ihrer Website“ beim Assistenten zeigt dafür in der App Schnipsel, Vorschau, erlaubte Domains und den Einbindungszustand an einem Ort. Die Vorschau sperrt die Eingabe und gilt nicht als Einbindung auf der Zielseite; aussagekräftig für Ihre Richtlinie ist deshalb nur der Lauf auf einer Seite, die sie tatsächlich ausliefert. Auf Wunsch gibt es dafür vorab einen Testassistenten für Ihre Seite. Welche Testfälle vor einem Livegang zusammengehören, beschreibt der Beitrag zur Abnahme mit Testfällen.

Was die Einbindung nicht mitbringt

Zu einer ehrlichen Planung gehören die Grenzen. Die Integrationsseite führt sie als eingestandene Grenzen auf, erhoben aus dem Quellstand. Für die Arbeit an einer Richtlinie sind diese Punkte die wichtigsten:

• Ohne JavaScript erscheint nichts. Hülle, Auslöser und Rahmen entstehen im Lader; einen Ersatzweg gibt es nicht.
• Nur ein Widget je Seite. Ein zweiter Schnipsel mit einem anderen Schlüssel kehrt still zurück und meldet nichts.
• Lässt Ihre Richtlinie Datenadressen für Bilder nicht zu, erscheint ein hinterlegtes Auslöserbild nicht; der Auslöser zeigt dann die Punkte der Marke.
• Die Angabe des Wirts ist selbstgemeldet, und ohne Domainliste ist jeder Wirt erlaubt.
• Wer die Gesprächskennung kennt, kann den Verlauf abrufen; ein weiteres Geheimnis gibt es nicht. Die Kennung liegt mit Frist im Speicher Ihrer Seite. Skripte dort, auch eingebundene Fremdskripte, haben damit grundsätzlich Zugang zum Verlauf.
• Fällt der Widgetdienst aus, gibt es keinen Rückfall auf eine andere Auslieferung. Das ist Absicht, weil ein Rückfall den Ausfall verdeckte.

Prüfliste vor dem Code-Freeze

• Bestandsaufnahme: Welche Sicherheits-Header setzt Ihre Seite heute, und steht die Content-Security-Policy in der Antwort des Servers oder in einem meta-Element?
• Für jedes eingebettete Element, auch das Chatfenster, die dokumentierten Anforderungen an die Richtlinie einholen und Lücken als offene Frage notieren.
• Den Auslieferungsweg festlegen, Widgetdomain oder eigener Pfad, und klären, wer die Serverkonfiguration dafür betreut.
• Die Domainliste des Assistenten füllen, bevor die Zeile live geht; eine leere Liste erlaubt jeden Wirt.
• Die neue Richtlinie zuerst im Berichtsmodus ausliefern, das Widget öffnen, ein Gespräch führen und die gemeldeten Verletzungen auswerten.
• Im Entwicklerwerkzeug des Browsers nachsehen, dass der Rahmen ohne allow-same-origin läuft und die Teile im Rahmen ihre Prüfsumme tragen.
• Erst dann scharf schalten, mit Abstand zum Stichtag des Code-Freeze, und die Einbindung danach auf der Live-Seite erneut prüfen.

Der wichtigste Punkt auf dieser Liste ist der Abstand. Eine Richtlinie, die kurz vor dem Stichtag scharf geschaltet wird, lässt keine Zeit, einen übersehenen Verstoß zu beheben, ohne den Freeze zu brechen. Die beiden Einträge für Ladeskript und Rahmen gehören darum schon in die Fassung, die im Berichtsmodus läuft; die technischen Einzelheiten der Einbindung stehen auf der Seite zur Integration.

Häufige Fragen