Où les réglages par défaut de la censure des PII en relecture de session exposent vos données

Qu'est-ce que la censure des PII en relecture de session ?

L'essentiel de la censure des PII en relecture de session, c'est qu'elle se produit dans le navigateur du visiteur, avant que l'enregistreur ne sérialise le DOM et n'envoie quoi que ce soit sur le réseau, et c'est pourquoi une règle ajoutée aujourd'hui ne change rien à un enregistrement capturé hier. Un script de relecture ne filme pas l'écran. Il parcourt le DOM, sérialise chaque noeud et diffuse les mutations, si bien que censurer revient à décider quels noeuds transmettent des valeurs réelles, lesquels transmettent des caractères de substitution et lesquels sont abandonnés puis rejoués comme une boîte vide.

Trois verbes couvrent les résultats possibles, sous des noms différents dans chaque bibliothèque. Bloquer abandonne l'élément et rejoue un substitut aux mêmes dimensions. Masquer conserve l'élément et remplace son texte. Ignorer garde l'élément visible mais cesse d'enregistrer ce que l'utilisateur a saisi. Mal choisir entre masquer et bloquer est l'erreur la plus fréquente, car les éléments masqués portent encore des données d'interaction et portent encore la longueur.

Le cadre de conformité, rétention et consentement compris, se trouve dans le guide du masquage de confidentialité de la relecture de session. Cette page couvre la mécanique en dessous : noms exacts des options, réglages par défaut livrés et endroits où ils fuient.

Trois verbes, un nœud du DOM

BloquerSupprime l'élément et rejoue un espace réservé aux mêmes dimensions

MasquerConserve l'élément, remplace son texte, révèle toujours la longueur et les données d'interaction

IgnorerGarde l'élément visible, arrête d'enregistrer ce que l'utilisateur a saisi

Quelles options de rrweb contrôlent ce qui est enregistré ?

rrweb, l'enregistreur open source derrière une longue liste de produits de relecture commerciaux, expose ces options de confidentialité sur rrweb.record() avec ces valeurs par défaut documentées.

Option	Valeur par défaut	Rôle
blockClass	'rr-block'	L'élément n'est pas enregistré et est rejoué comme un substitut aux mêmes dimensions
blockSelector	null	Identique à blockClass mais avec une correspondance par sélecteur CSS
ignoreClass	'rr-ignore'	L'élément s'affiche normalement mais ses événements de saisie ne sont pas enregistrés
ignoreSelector	null	Identique à ignoreClass mais avec une correspondance par sélecteur CSS
maskTextClass	'rr-mask'	Tout le texte de l'élément et de ses enfants est masqué
maskTextSelector	null	Identique à maskTextClass mais avec une correspondance par sélecteur CSS
maskAllInputs	false	Masque le contenu de chaque champ de saisie par *
maskInputOptions	{ password: true }	Masque des types de saisie précis
maskInputFn	aucune	Remplace la logique de masquage des saisies par défaut
maskTextFn	aucune	Remplace la logique de masquage du texte par défaut

Le guide de rrweb énonce le réglage livré en une ligne : input[type="password"] will be masked by default.

Ce que la liste ne contient pas, c'est une option de démasquage. Les options d'enregistrement de rrweb ne comportent ni unmaskTextClass ni unblockSelector, donc un masque posé sur un conteneur ne peut pas être levé sur un seul enfant à l'intérieur. Les fournisseurs qui proposent le démasquage, dont Sentry et FullStory, ont construit cette couche eux-mêmes.

Que masque rrweb par défaut ?

Tel quel, rrweb masque exactement une chose : la valeur de input[type="password"]. Le texte et tous les autres types de saisie sont enregistrés mot pour mot, si bien que les champs e-mail, nom, adresse, numéro de carte et texte libre quittent le navigateur avec leur contenu réel tant que vous ne les configurez pas autrement.

Deux détails du code source de rrweb transforment ce réglage en piège. Le premier est que maskInputOptions remplace la valeur par défaut au lieu de fusionner avec elle. Passez maskInputOptions: { email: true } parce que vous voulez couvrir les e-mails et vous avez désactivé en silence le masquage des mots de passe. La forme sûre écrit { password: true, email: true } à chaque fois.

Le second est la forme du type MaskInputOptions. Il accepte color, date, datetime-local, email, month, number, range, search, tel, text, time, url, week, textarea, select et password, et il n'accepte ni checkbox, ni radio, ni file. Régler maskAllInputs: true se déploie sur chaque clé de cette liste, donc même le réglage maximal de masquage des saisies enregistre quelles cases à cocher et quels boutons radio un visiteur a sélectionnés. Sur un formulaire d'admission médicale, la case à cocher est la donnée sensible. FullStory règle cela en excluant plutôt qu'en masquant : sa fonction Form Privacy "masks all form elements with the attributes input, textarea, select, and contenteditable, and exclude all form elements with the attributes radio and checkbox."

En quoi les fournisseurs de relecture de session diffèrent-ils sur les réglages de masquage ?

Les fournisseurs se placent aux extrémités opposées de la même boîte à outils, et le réglage par défaut décide du coût d'une règle oubliée.

Outil	Masqué sans configuration	Mécanisme de retrait
rrweb	Uniquement input[type="password"]	Aucun ; il n'existe pas d'option de démasquage
PostHog	Toutes les saisies (maskAllInputs vaut true par défaut) ; le texte n'est pas masqué	Classe ph-no-capture
Sentry	Tout le texte (maskAllText: true), toutes les saisies, tous les médias (blockAllMedia: true)	.sentry-unmask, .sentry-unblock, aucune appliquée par défaut
Microsoft Clarity	Nombres et adresses e-mail dans le mode Balanced par défaut ; saisies et listes déroulantes dans tous les modes	data-clarity-unmask="true"
FullStory avec Private by Default	Chaque élément, capturé masqué	.fs-unmask
LogRocket	Rien ; inputSanitizer et textSanitizer valent false par défaut	data-public

Sentry énonce sa position sans détour : "by default, the Session Replay SDK will mask all text content with * and block all media elements." Clarity propose le compromis inverse via trois modes, où Strict masque "the entire content", Balanced masque "numbers and email addresses" et Relaxed ne masque rien au-delà des saisies et des listes déroulantes. Deux comportements de Clarity ne sont pas configurables du tout : "Content in the input boxes is masked in all modes and can't be customized" et "The drop-down menus are also masked in all modes." Clarity signale ce qu'il a caché par ▫ pour un chiffre, ▪ pour une lettre et • pour le mode Strict.

Pourquoi le texte masqué laisse-t-il encore fuiter de l'information ?

Le texte masqué laisse fuiter la longueur de ce qu'il a remplacé, parce que les enregistreurs les plus déployés substituent un caractère de remplacement par caractère d'origine. La fonction de masquage de rrweb s'écrit littéralement text = '*'.repeat(text.length). La fonction de masque par défaut de Sentry est (s) => '*'.repeat(s.length). FullStory est explicite : "This placeholder text blob will retain the size, color, and character length of the original text."

La documentation de FullStory rend le risque concret pour un champ comme le solde d'un compte : "if you were comparing the session replays of 2 different accounts, and one showed a placeholder string for account balance that was three inches long and the other had a placeholder string that was half an inch long, you now know more about these two accounts than you probably need to."

La longueur n'est pas le seul canal. Les éléments masqués enregistrent encore les interactions, et c'est pourquoi FullStory dit à ses clients du secteur de la santé d'exclure à la place : "Because masked elements collect interaction data, it would be possible for someone with good working knowledge of the product to understand which health issues a user was checking the boxes for."

Le correctif est le même dans les deux cas. Renvoyez une chaîne de longueur fixe depuis une maskTextFn ou une maskInputFn personnalisée au lieu d'une chaîne calculée caractère par caractère, et faites passer tout ce qui permet une inférence du masquage au blocage. L'écart entre réduire l'identifiabilité et la supprimer, c'est la différence entre pseudonymisation et anonymisation.

Qu'est-ce qui échappe aux règles de masquage ?

Les règles de masquage s'appliquent aux noeuds de texte du DOM et aux valeurs de saisie, donc tout ce qui porte des données en dehors de ces deux endroits reste dans l'enregistrement. Chaque fournisseur documente son propre angle mort.

• Feuilles de style. Clarity "doesn't mask content within style sheets or style tags. Hence, it is recommended not to host sensitive content within CSS."
• SVG en ligne. Hotjar : "SVGs linked as the source for image elements can be suppressed, but inline SVGs cannot."
• Images sur le web. FullStory : "Images cannot be masked when capturing data on web sessions. If you wish to hide images from data capture, use .fs-exclude."
• URL et charges utiles réseau. Une page masquée dont la chaîne de requête contient un numéro de compte l'expédie quand même. PostHog expose maskCapturedNetworkRequestFn ; FullStory place les corps de requête et de réponse sur liste d'autorisation.
• Propriétés d'événements personnalisés. La censure régit le flux de relecture, pas les événements analytiques que votre propre code envoie.

Le masquage peut-il s'appliquer aux enregistrements que vous avez déjà ?

Aucun fournisseur ne peut censurer rétroactivement une session qui a déjà atteint ses serveurs, et deux le disent noir sur blanc. Clarity : "Changes to masking settings affect new recordings and could take up to one hour to be reflected. Masking changes can't be applied retroactively." Hotjar : "After a session is sent, there is no way to retrieve or suppress data, and updating suppression settings will not apply the updated settings retroactively."

Le chiffre d'une heure est la partie que les équipes manquent. Ajouter une règle après avoir repéré des numéros de carte dans une relecture laisse jusqu'à une heure d'enregistrements supplémentaires les capturer, en plus de tout ce qui est déjà stocké. Les remèdes sont de supprimer les enregistrements concernés et de raccourcir la rétention, ce qui fait de la durée de rétention un contrôle de censure plutôt qu'un réglage de stockage. C'est aussi pourquoi les plaignants dans les procès pour écoute illégale liés à la relecture de session débattent de ce qui a été capturé plutôt que de ce qui a ensuite été caché dans l'interface de relecture.

Faut-il tout masquer puis démasquer, ou l'inverse ?

Masquez tout par défaut et démasquez ce que vous avez vérifié, parce que le mode de défaillance d'une liste de blocage est de capturer des données que vous n'avez jamais voulues et celui d'une liste d'autorisation est une relecture ennuyeuse. FullStory a bâti Private by Default sur ce raisonnement : "no text is captured or sent outside the user's browser unless it is explicitly allowlisted as safe to capture", de sorte que "you won't accidentally capture unwanted data even if you fail to set specific data capture rules."

Réglez la question de la priorité avant d'écrire le premier sélecteur. FullStory tranche les conflits en faveur de la confidentialité : "if an element matches both a masking rule and an unmasking rule, it would be masked rather than unmasked, as the stricter rule will always apply." Clarity fait l'inverse pour les attributs : data-clarity-unmask="true" démasque un noeud et ses enfants et "overrides anything set on the Clarity website." Deux produits, deux réponses opposées.

Gardez les règles dans le code plutôt que dans un tableau de bord. FullStory qualifie l'approche par le code de "a less brittle and more future-proof approach than handling these rules through the UI using CSS selectors", parce qu'un sélecteur écrit dans un écran de réglages casse en silence quand une bibliothèque de composants livre de nouveaux noms de classes.

Flowsery fonctionne sans cookies et enregistre les sessions sans échantillonnage. Si vous en êtes encore à décider ce que la relecture capture, commencez par ce qu'est la relecture de session, puis fixez la politique de masquage avant que la première balise de script ne passe en production.

Questions fréquentes

Le masquage en relecture de session intervient-il avant ou après l'envoi des données ?

Avant, dans tous les produits documentés ici. Clarity "never captures anything that is masked or sent over the wire", et Hotjar décrit la suppression comme le retrait des données personnelles "before sending a session from your website's Document Object Model (DOM) to Hotjar". Un masquage appliqué au moment de la lecture est un filtre d'affichage, pas une censure.

maskAllInputs: true couvre-t-il tous les champs de formulaire dans rrweb ?

Non. Il se déploie sur chaque clé du type MaskInputOptions de rrweb, qui omet checkbox, radio et file, donc l'état des cases à cocher et des boutons radio continue d'être enregistré. Bloquez plutôt ces éléments, comme le fait Form Privacy de FullStory.

Puis-je démasquer un champ à l'intérieur d'un conteneur masqué ?

Cela dépend du produit, et rrweb seul ne le peut pas. Les options d'enregistrement de rrweb ne comportent aucune classe ni aucun sélecteur de démasquage, donc un masque posé sur un parent couvre chaque enfant. FullStory et Sentry ajoutent le démasquage par-dessus, Sentry livrant .sentry-unmask et .sentry-unblock appliqués à rien par défaut.

Quelle est la différence entre masquer et bloquer un élément ?

Masquer conserve l'élément et remplace son texte ; bloquer retire l'élément et rejoue un substitut. FullStory trace la ligne selon le risque d'inférence et recommande l'exclusion pour les données réglementées, pour les identifiants comme les numéros de compte bancaire et pour tout élément où la seule interaction révèle quelque chose de personnel.

Les enregistrements masqués comptent-ils encore comme des données personnelles ?

Traitez-les comme des données personnelles tant que vous n'avez pas prouvé le contraire. Un masquage qui préserve la longueur des caractères, les coordonnées de clic et la structure des éléments réduit l'identifiabilité sans la supprimer, ce qui relève de la pseudonymisation et non de l'anonymisation, et les données pseudonymisées restent dans le champ du RGPD.

Combien de temps une règle de masquage ajoutée met-elle à prendre effet ?

Sur Clarity le chiffre documenté est d'une heure au maximum, et uniquement pour les nouveaux enregistrements. Les règles côté client dans rrweb, Sentry, PostHog et LogRocket prennent effet au prochain chargement de page servant le script mis à jour, donc un bundle en cache ou un TTL CDN long allonge la fenêtre pendant laquelle les anciennes règles s'appliquent encore.

Quel outil de relecture de session masque le plus par défaut ?

Sentry applique le réglage par défaut le plus strict parmi les outils traités ici : il masque tout le texte (maskAllText: true), masque chaque champ de saisie et bloque tous les médias (blockAllMedia: true). rrweb se situe à l'autre extrémité, ne masquant par défaut que input[type="password"] tant qu'on ne configure rien d'autre. Choisir un fournisseur sans vérifier ces réglages par défaut revient à décider de ce qui reste exposé avant même d'écrire une seule règle.

PostHog masque-t-il le texte par défaut ?

PostHog ne masque pas le texte par défaut. Il masque tous les champs de saisie, puisque maskAllInputs vaut true par défaut, mais les nœuds de texte sont enregistrés tels quels sans règle supplémentaire. La classe ph-no-capture permet de retirer certains éléments de l'enregistrement, remplacés par un bloc de même taille.

Peut-on masquer les SVG en ligne ou les feuilles de style en relecture de session ?

Les règles de masquage s'appliquent aux nœuds de texte du DOM et aux valeurs des champs de saisie, donc tout ce qui sort de ces deux endroits leur échappe. Clarity ne masque pas le contenu des feuilles de style ni des balises style, ce qui explique sa recommandation de ne pas héberger de contenu sensible en CSS. Hotjar précise que les SVG utilisés comme source d'image peuvent être supprimés, mais que les SVG en ligne ne le peuvent pas.

Les règles de masquage doivent-elles vivre dans le code ou dans un tableau de bord ?

Mieux vaut les garder dans le code. FullStory qualifie l'approche code d'abord de moins fragile que la gestion des règles via l'interface avec des sélecteurs CSS, car un sélecteur défini dans un écran de configuration casse silencieusement dès qu'une bibliothèque de composants change ses noms de classes. Versionner les règles avec l'application permet de livrer et d'annuler un changement comme n'importe quel autre code.