Confidentialité et sécurité dans RSS Reader : comment les flux sont chargés et ce qui est envoyé

Introduction

Un composant WebPart qui amène sur l'intranet du contenu provenant de l'extérieur de l'entreprise soulève deux questions pour un administrateur : qu'est-ce qui sort du locataire, et qu'est-ce qui y entre. RSS Reader est inhabituel parmi les produits Vitextra en ce que son contenu transite bel et bien par un serveur Vitextra — le service de flux qui télécharge les flux. Cet article indique précisément ce que contient cette requête, ce que le composant WebPart est autorisé à faire dans votre locataire, où réside sa configuration, ce qu'il conserve dans le navigateur et comment il traite le HTML que les éditeurs placent dans leurs flux.

Résumé pour les administrateurs

Autorisations de la solution

RSS Reader est un composant WebPart SharePoint Framework déployé depuis le catalogue d'applications.

• Le package ne demande aucune autorisation d'API. Rien n'apparaît sur la page Accès aux API (API access) du Centre d'administration SharePoint, et le composant WebPart n'appelle ni Microsoft Graph ni l'API REST SharePoint pour obtenir des données.
• Du contexte de la page, il ne lit que ce dont dispose tout composant WebPart : le thème, la langue, l'adresse du site (pour la vérification de licence et la requête de flux) et l'identité de l'utilisateur connecté (l'ID d'objet, pour les mêmes requêtes).
• Il n'écrit rien dans SharePoint, OneDrive ou Microsoft Entra ID.

Ce dont les utilisateurs ont besoin

Comment les flux sont chargés et ce qui est envoyé

Les navigateurs n'autorisent pas un script d'un site web à télécharger un document depuis un autre site web, sauf si ce site le permet au moyen d'en-têtes cross-origin ; les éditeurs de flux ne le font presque jamais. Un composant WebPart RSS fonctionnant uniquement dans le navigateur échouerait donc pour la plupart des flux. RSS Reader résout ce problème avec un service de flux côté serveur hébergé sur vitextra.com : le navigateur lui envoie la liste des adresses des flux, le service télécharge les flux depuis Internet, les analyse et renvoie les canaux et les éléments sous forme de données structurées.

Chaque chargement et chaque actualisation automatique constituent une requête au service de flux, dont voici le contenu :

La réponse contient les éléments des flux — titres, liens, descriptions, dates, auteurs, catégories et adresses des images — ainsi que la liste des sources qui n'ont pas pu être téléchargées. Le service ne reçoit ni ne renvoie aucun contenu de votre locataire ; l'utilisateur est identifié par un GUID, et non par son nom ou son adresse e-mail.

Trois conséquences :

• les adresses des flux que vous configurez sont connues du service de flux. N'utilisez pas de flux dont l'adresse contient elle-même un secret (un jeton personnel ou une clé d'API dans la chaîne de requête) : ces flux ne sont pas destinés à être partagés avec un agrégateur, et ils ne sont de toute façon pas pris en charge, car le service télécharge les flux de façon anonyme ;
• les flux accessibles uniquement à l'intérieur de votre réseau ne peuvent pas être affichés ;
• le navigateur ne se connecte jamais aux serveurs des éditeurs pour le flux. Il s'y connecte en revanche pour les images des éléments, qui sont chargées directement par le navigateur comme n'importe quelle image d'une page web — l'éditeur voit la requête d'image ordinaire du navigateur de l'utilisateur.

Où la configuration est stockée

Sur une page SharePoint, la configuration — les flux avec leurs adresses, noms et ordre, la mise en page et les commutateurs — est stockée dans les propriétés du composant WebPart, à l'intérieur de la page dans la bibliothèque Pages du site. Toute personne qui peut lire la page peut lire la configuration (les adresses des flux sont de toute façon visibles dans les onglets de sources) ; les versions de la page conservent les configurations antérieures.

Pour l'application personnelle Teams, un administrateur enregistre la configuration avec Enregistrer les paramètres dans le groupe Application personnelle (Microsoft Teams). Cette configuration — les mêmes champs, sans le titre du composant WebPart — est stockée par le service Vitextra pour votre locataire et votre produit, car l'application personnelle n'a aucune page où la stocker. Elle est lue par l'application personnelle de chaque utilisateur du locataire et remplacée par le prochain Enregistrer les paramètres. Elle ne contient que des paramètres et des adresses de flux, aucune donnée utilisateur.

Dans un onglet de canal Teams, la configuration est stockée avec l'onglet, comme sur une page.

Ce qui est conservé dans le navigateur

Après un chargement réussi, le composant WebPart écrit les éléments reçus dans le stockage de session du navigateur, indexés par le jeu d'adresses des flux, et les utilise pendant 30 minutes au plus pour afficher instantanément le contenu à la visite suivante pendant que les nouveaux éléments se chargent en arrière-plan. Le cache contient les éléments de flux tels que renvoyés par le service de flux et rien concernant l'utilisateur ; il appartient à la session de l'onglet du navigateur et est supprimé à la fermeture de l'onglet. Le composant WebPart n'utilise ni le stockage local, ni les cookies, ni aucun autre stockage persistant.

Les articles qu'un utilisateur a ouverts ne sont enregistrés nulle part. L'estompage des titres déjà ouverts repose sur la mémoire des liens visités propre au navigateur, qu'aucun script ne peut lire.

Comment le contenu des flux est affiché

Les éléments de flux contiennent du HTML écrit par l'éditeur — des descriptions avec balisage, des images incorporées, parfois des scripts ou des pixels de suivi. RSS Reader n'insère jamais ce HTML dans la page :

• la description est analysée avec un analyseur inerte (DOMParser), qui n'exécute aucun script et ne charge aucune ressource incorporée, et seul son texte brut est affiché ;
• l'image d'un élément est tirée des éléments média du flux ou de la première image de la description, et les images d'un pixel — les pixels de suivi typiques — sont ignorées ; l'image est ensuite affichée comme un élément <img> ordinaire avec l'adresse de l'éditeur ;
• les liens ouvrent l'article d'origine dans un nouvel onglet sur le site de l'éditeur ; le composant WebPart n'ajoute aucun paramètre de suivi.

Un élément malformé — éléments manquants, balisage corrompu — est affiché avec les données dont il dispose et n'empêche pas l'affichage des autres éléments.

Requêtes vers les services Vitextra

Pour les mêmes informations à l'échelle de tous les produits Vitextra, voir KB10363. Où les produits Vitextra stockent vos données : confidentialité, résidence des données et RGPD.

Exigences réseau

Autorisez le trafic HTTPS sortant depuis le réseau des utilisateurs (et depuis le client Teams) vers vitextra.com, static.vitextra.com et vitextra-storage.azureedge.net. Sans le premier hôte, le composant WebPart affiche Désolé, nous avons rencontré un problème… à la place des éléments ; sans les deux autres, il ne se charge pas du tout. Les images des éléments sont chargées depuis les hôtes des éditeurs ; si votre proxy bloque un éditeur, ses éléments apparaissent sans images.

Recommandations

1. Utilisez les flux d'éditeurs auxquels votre organisation fait confiance, comme pour tout contenu externe sur l'intranet : les titres, les textes et les images sont les leurs et changent sans votre relecture.
2. Préférez les adresses de flux en HTTPS avec des images en HTTPS ; les images servies en HTTP sont bloquées par le navigateur sur les pages HTTPS.
3. Ne configurez pas de flux dont l'adresse contient un jeton personnel ; ils sont partagés avec toute personne qui peut lire la page et avec le service de flux.
4. Sur les ordinateurs partagés, effacez les données de site du navigateur à la déconnexion, comme pour toute page de l'intranet ; le cache des flux disparaît de toute façon avec l'onglet.