--- title: "Datenschutz und Sicherheit in RSS Reader: Wie Feeds geladen werden und was gesendet wird" description: "Referenz zum Umgang mit Daten im Vitextra RSS Reader-Webpart: warum Feeds vom Vitextra-Feeddienst statt vom Browser heruntergeladen werden, was die Anfrage genau enthält, welche Berechtigungen die Lösung benötigt (keine), wo die Konfiguration gespeichert wird und wer sie lesen kann, was im Browser aufbewahrt wird, wie nicht vertrauenswürdige Feedinhalte sicher dargestellt werden, welche Hosts im Netzwerk zuzulassen sind und Empfehlungen zur Auswahl von Feeds." url: https://vitextra.com/de/support/kb/10374 language: de published: 2026-10-30 modified: 2026-10-30 products: - "RSS Reader" author: "Lidija Reising" tags: ["RSS Reader Datenschutz", "RSS-Webpart Sicherheit", "RSS-Proxy vitextra.com was wird gesendet", "SPFx-Webpart ohne API-Berechtigungen", "Feedinhalt bereinigt XSS", "RSS-Webpart Datenspeicherung", "Webpart Telemetrie Lizenzprüfung", "Hosts zulassen Firewall SharePoint-Webpart", "externe Inhalte Intranet Sicherheit", "Vitextra RSS Reader"] --- # Datenschutz und Sicherheit in RSS Reader: Wie Feeds geladen werden und was gesendet wird Referenz zum Umgang mit Daten im Vitextra RSS Reader-Webpart: warum Feeds vom Vitextra-Feeddienst statt vom Browser heruntergeladen werden, was die Anfrage genau enthält, welche Berechtigungen die Lösung benötigt (keine), wo die Konfiguration gespeichert wird und wer sie lesen kann, was im Browser aufbewahrt wird, wie nicht vertrauenswürdige Feedinhalte sicher dargestellt werden, welche Hosts im Netzwerk zuzulassen sind und Empfehlungen zur Auswahl von Feeds. ## Einführung Ein Webpart, das Inhalte von außerhalb des Unternehmens ins Intranet bringt, wirft für einen Administrator zwei Fragen auf: Was verlässt den Mandanten, und was kommt herein? [RSS Reader](https://vitextra.com/de/products/rss-news) ist unter den Vitextra-Produkten insofern ungewöhnlich, als seine Inhalte tatsächlich über einen Vitextra-Server laufen – den Feeddienst, der die Feeds herunterlädt. Dieser Artikel beschreibt genau, was diese Anfrage enthält, was das Webpart in Ihrem Mandanten tun darf, wo seine Konfiguration liegt, was es im Browser aufbewahrt und wie es mit dem HTML umgeht, das Herausgeber in ihre Feeds einfügen. ## Zusammenfassung für Administratoren | Frage | Antwort | |---|---| | Welche API-Berechtigungen fordert das Paket an? | Keine | | Liest das Webpart SharePoint-Listen, Dateien oder Benutzerprofile? | Nein | | Wer lädt die Feeds herunter? | Der Vitextra-Feeddienst, auf Anfrage des Browsers | | Was enthält die Anfrage an den Feeddienst? | Die Feedadressen, die Mandanten-ID, die Objekt-ID des Benutzers, die Websiteadresse, das Produkt und seine Version | | Werden Inhalte Ihres Mandanten an Vitextra gesendet? | Nein | | Wo wird die Konfiguration gespeichert? | In den Webpart-Eigenschaften auf der Seite; für die persönliche Teams-App im Vitextra-Dienst für Ihren Mandanten | | Was wird im Browser aufbewahrt? | Die zuletzt geladenen Feedelemente, bis zu 30 Minuten der Registerkartensitzung | | Wird Feed-HTML auf der Seite ausgeführt? | Nein – es wird inert analysiert; nur Nur-Text und Bildadressen werden verwendet | ## Berechtigungen der Lösung RSS Reader ist ein ::SharePoint Framework::-Webpart, das aus dem ::App-Katalog:: bereitgestellt wird. - Das Paket fordert **keine API-Berechtigungen** an. Auf der Seite **API-Zugriff** des SharePoint Admin Centers erscheint nichts, und das Webpart ruft für Daten weder Microsoft Graph noch die SharePoint-REST-API auf. - Aus dem Seitenkontext liest es nur, was jedes Webpart hat: das Design, die Sprache, die Websiteadresse (für die Lizenzprüfung und die Feedanfrage) und die Identität des angemeldeten Benutzers (die Objekt-ID, für dieselben Anfragen). - Es schreibt nichts in SharePoint, OneDrive oder Microsoft Entra ID. ## Was Benutzer benötigen | Aufgabe | Erforderliche Berechtigung | |---|---| | Das Paket in den App-Katalog hochladen, zu Teams hinzufügen | SharePoint-Administrator oder Besitzer des App-Katalogs | | Das Webpart einer Seite hinzufügen und die Feeds konfigurieren | Bearbeitungsberechtigung für die Seite | | Die Standardkonfiguration der persönlichen Teams-App speichern | Bearbeitungsberechtigung für eine Seite mit dem Webpart | | Die Feeds lesen, Quellen wechseln, filtern und suchen | Leseberechtigung für die Seite | ## Wie Feeds geladen werden und was gesendet wird Browser erlauben es einem Skript auf einer Website nicht, ein Dokument von einer anderen Website herunterzuladen, sofern diese Website es nicht mit Cross-Origin-Headern gestattet; Feedherausgeber tun das fast nie. Ein reines Browser-RSS-Webpart würde daher bei den meisten Feeds scheitern. RSS Reader löst dies mit einem serverseitigen **Feeddienst** unter `vitextra.com`: Der Browser sendet ihm die Liste der Feedadressen, der Dienst lädt die Feeds aus dem Internet herunter, analysiert sie und gibt die Kanäle und Elemente als strukturierte Daten zurück. Jedes Laden und jede automatische Aktualisierung ist eine Anfrage an den Feeddienst mit folgendem Inhalt: | Feld | Wert | |---|---| | Sources | Die Adressen der konfigurierten Feeds | | TenantId | Die ID Ihres Microsoft 365-Mandanten | | UserId | Die Objekt-ID (GUID) des angemeldeten Benutzers in Microsoft Entra ID | | SiteUrl | Die Adresse der Website, auf der das Webpart ausgeführt wird | | ProductId, ProductName, ProductVersion | Bezeichner, interner Name und Version des Produkts | Die Antwort enthält die Feedelemente – Titel, Links, Beschreibungen, Datumsangaben, Autoren, Kategorien und Bildadressen – und die Liste der Quellen, die nicht heruntergeladen werden konnten. Der Dienst empfängt keine Inhalte Ihres Mandanten und gibt keine zurück; der Benutzer wird über eine GUID identifiziert, nicht über Namen oder E-Mail-Adresse. Drei Konsequenzen: - die **Feedadressen**, die Sie konfigurieren, sind dem Feeddienst bekannt. Verwenden Sie keine Feeds, deren Adresse selbst ein Geheimnis enthält (ein persönliches Token oder einen API-Schlüssel in der Abfragezeichenfolge): Solche Feeds sind nicht dafür gedacht, mit einem Aggregator geteilt zu werden, und werden ohnehin nicht unterstützt, weil der Dienst Feeds anonym herunterlädt; - Feeds, die nur innerhalb Ihres Netzwerks erreichbar sind, können nicht angezeigt werden; - der Browser stellt für den Feed nie eine Verbindung zu den Servern der Herausgeber her. Er verbindet sich mit ihnen für die **Bilder** der Elemente, die der Browser wie jedes Bild auf einer Webseite direkt lädt – der Herausgeber sieht die gewöhnliche Bildanfrage des Browsers des Benutzers. 📝 **Hinweis** Die Verarbeitung dieser Anfragen durch Vitextra ist in der [Datenschutzerklärung](https://vitextra.com/de/privacy) beschrieben. Die Anfrage teilt dem Dienst mit, mit welchen Feeds eine Seite konfiguriert ist, nicht welche Artikel ein Benutzer öffnet – die Links zu den Artikeln führen direkt zum Herausgeber, und kein Klick wird an Vitextra gemeldet. ## Wo die Konfiguration gespeichert wird **Auf einer SharePoint-Seite** wird die Konfiguration – die Feeds mit ihren Adressen, Namen und ihrer Reihenfolge, das Layout und die Schalter – in den **Eigenschaften des Webparts** innerhalb der Seite in der Bibliothek **Websiteseiten** gespeichert. Jeder, der die Seite lesen kann, kann die Konfiguration lesen (die Feedadressen sind in den Quellenregisterkarten ohnehin sichtbar); Seitenversionen bewahren frühere Konfigurationen auf. **Für die persönliche Teams-App** speichert ein Administrator die Konfiguration mit **Einstellungen speichern** in der Gruppe **Persönliche App (Microsoft Teams)**. Diese Konfiguration – dieselben Felder, ohne den Webparttitel – wird vom Vitextra-Dienst für Ihren Mandanten und Ihr Produkt gespeichert, weil die persönliche App keine Seite hat, in der sie gespeichert werden könnte. Sie wird von der persönlichen App jedes Benutzers im Mandanten gelesen und vom nächsten **Einstellungen speichern** überschrieben. Sie enthält nur Einstellungen und Feedadressen, keine Benutzerdaten. **In einer Teams-Kanalregisterkarte** wird die Konfiguration mit der Registerkarte gespeichert, wie auf einer Seite. ## Was im Browser aufbewahrt wird Nach einem erfolgreichen Laden schreibt das Webpart die empfangenen Elemente in den **Sitzungsspeicher** des Browsers, mit dem Satz der Feedadressen als Schlüssel, und verwendet sie bis zu 30 Minuten lang, um beim nächsten Besuch sofort Inhalte zu zeigen, während aktuelle Elemente im Hintergrund geladen werden. Der Cache enthält die Feedelemente, wie sie vom Feeddienst zurückgegeben wurden, und nichts über den Benutzer; er gehört zur Browserregisterkartensitzung und wird entfernt, wenn die Registerkarte geschlossen wird. Das Webpart verwendet weder den lokalen Speicher noch Cookies oder einen anderen dauerhaften Speicher. Welche Artikel ein Benutzer geöffnet hat, wird **nirgends** aufgezeichnet. Das Abblenden bereits geöffneter Titel beruht auf dem browsereigenen Verlauf besuchter Links, den kein Skript lesen kann. ## Wie Feedinhalte dargestellt werden Feedelemente enthalten vom Herausgeber geschriebenes HTML – Beschreibungen mit Markup, eingebettete Bilder, manchmal Skripts oder Tracking-Pixel. RSS Reader fügt dieses HTML nie in die Seite ein: - die Beschreibung wird mit einem **inerten Parser** (`DOMParser`) analysiert, der weder Skripts ausführt noch eingebettete Ressourcen lädt, und nur ihr **Nur-Text** wird angezeigt; - das Bild eines Elements wird aus den Medienelementen des Feeds oder aus dem ersten Bild der Beschreibung übernommen, und Bilder von einem Pixel – die typischen Tracking-Pixel – werden übersprungen; das Bild wird dann als gewöhnliches ``-Element mit der Adresse des Herausgebers angezeigt; - Links öffnen den Originalartikel in einer neuen Registerkarte auf der Website des Herausgebers; das Webpart fügt keine Tracking-Parameter hinzu. Ein fehlerhaftes Element – fehlende Elemente, defektes Markup – wird mit den vorhandenen Daten angezeigt und verhindert nicht die Darstellung der anderen Elemente. ## Anfragen an Vitextra-Dienste | Zweck | Was gesendet wird | Wohin | |---|---|---| | **Feeddienst** | Siehe [die Tabelle oben](#feed-request) | `vitextra.com` | | **Lizenzprüfung** | Die Mandanten-ID, die Objekt-ID des Benutzers, die Websiteadresse sowie Bezeichner, Name und Version des Produkts | `vitextra.com` | | **Konfiguration der persönlichen Teams-App** | Gelesen bei jedem Laden der persönlichen App; geschrieben durch **Einstellungen speichern**: die oben aufgeführten Konfigurationsfelder | `vitextra.com` | | **Nutzungstelemetrie** | Ein Ereignis beim Laden des Webparts: Name und Version des Produkts, ID und Adresse der Website, die Objekt-ID des Benutzers, die Sprache der Benutzeroberfläche und ob das Webpart in Teams ausgeführt wird; technische Details von Fehlern | Azure Application Insights | | **Produktdateien** | Eine gewöhnliche Dateianforderung für die Skripts und Symbole des Webparts | `static.vitextra.com`, `vitextra-storage.azureedge.net` | Dieselben Informationen für alle Vitextra-Produkte finden Sie in [KB10363. Wo Vitextra-Produkte Ihre Daten speichern: Datenschutz, Datenresidenz und DSGVO](https://vitextra.com/de/support/kb/10363). ## Netzwerkanforderungen Lassen Sie ausgehendes HTTPS aus dem Netzwerk der Benutzer (und vom Teams-Client) zu `vitextra.com`, `static.vitextra.com` und `vitextra-storage.azureedge.net` zu. Ohne den ersten Host zeigt das Webpart *Leider ist ein Fehler aufgetreten…* anstelle der Elemente; ohne die beiden anderen wird es gar nicht geladen. Die Bilder der Elemente werden von den Hosts der Herausgeber geladen; blockiert Ihr Proxy einen Herausgeber, erscheinen dessen Elemente ohne Bilder. ## Empfehlungen 1. Verwenden Sie Feeds von Herausgebern, denen Ihre Organisation vertraut, wie bei allen externen Inhalten im Intranet: Titel, Texte und Bilder gehören ihnen und ändern sich ohne Ihre Prüfung. 2. Bevorzugen Sie HTTPS-Feedadressen mit HTTPS-Bildern; über HTTP ausgelieferte Bilder werden vom Browser auf HTTPS-Seiten blockiert. 3. Konfigurieren Sie keine Feeds, deren Adresse ein persönliches Token enthält; sie werden mit allen geteilt, die die Seite lesen können, und mit dem Feeddienst. 4. Löschen Sie auf gemeinsam genutzten Computern beim Abmelden die Websitedaten des Browsers wie bei jeder Intranetseite; der Feedcache verschwindet ohnehin mit der Registerkarte.