Dónde los valores por defecto de la redacción de PII en session replay dejan datos expuestos

¿Qué es la redacción de PII en session replay?

Lo esencial de la redacción de PII en session replay es que ocurre en el navegador del visitante, antes de que el grabador serialice el DOM y envíe nada por la red, y por eso una regla que añade hoy no hace nada por una grabación capturada ayer. Un script de replay no filma la pantalla. Recorre el DOM, serializa cada nodo y transmite mutaciones, así que redactar significa decidir qué nodos envían valores reales, cuáles envían caracteres de marcador y cuáles se descartan y se reproducen como una caja vacía.

Tres verbos cubren los resultados, con nombres distintos en cada biblioteca. Bloquear descarta el elemento y reproduce un marcador de las mismas dimensiones. Enmascarar conserva el elemento y sustituye su texto. Ignorar mantiene el elemento visible pero deja de grabar lo que el usuario escribió. Elegir mal entre enmascarar y bloquear es el error más común, porque los elementos enmascarados siguen llevando datos de interacción y siguen llevando la longitud.

El marco de cumplimiento, incluidas la retención y el consentimiento, está en la guía sobre el enmascaramiento de privacidad en session replay. Esta página cubre la mecánica que hay debajo: nombres exactos de las opciones, valores por defecto de fábrica y los puntos por donde se filtran.

Tres verbos, un nodo del DOM

BloquearElimina el elemento y reproduce un marcador de posición con las mismas dimensiones

EnmascararMantiene el elemento, sustituye su texto, sigue revelando longitud y datos de interacción

IgnorarMantiene el elemento visible, deja de grabar lo que el usuario escribió

¿Qué opciones de rrweb controlan lo que se graba?

rrweb, el grabador de código abierto detrás de una larga lista de productos comerciales de replay, expone estas opciones de privacidad en rrweb.record() con estos valores por defecto documentados.

Opción	Valor por defecto	Qué hace
blockClass	'rr-block'	El elemento no se graba y se reproduce como un marcador de las mismas dimensiones
blockSelector	null	Igual que blockClass pero con coincidencia por selector CSS
ignoreClass	'rr-ignore'	El elemento se muestra con normalidad pero sus eventos de entrada no se graban
ignoreSelector	null	Igual que ignoreClass pero con coincidencia por selector CSS
maskTextClass	'rr-mask'	Se enmascara todo el texto del elemento y de sus hijos
maskTextSelector	null	Igual que maskTextClass pero con coincidencia por selector CSS
maskAllInputs	false	Enmascara el contenido de cada entrada como *
maskInputOptions	{ password: true }	Enmascara tipos de entrada concretos
maskInputFn	ninguna	Sustituye la lógica de enmascaramiento de entradas por defecto
maskTextFn	ninguna	Sustituye la lógica de enmascaramiento de texto por defecto

La guía de rrweb declara el valor de fábrica en una línea: input[type="password"] will be masked by default.

Lo que la lista no contiene es una opción para desenmascarar. En las opciones de grabación de rrweb no existen unmaskTextClass ni unblockSelector, así que una máscara puesta sobre un contenedor no se puede levantar en uno de sus hijos. Los proveedores que ofrecen desenmascarado, entre ellos Sentry y FullStory, construyeron esa capa por su cuenta.

¿Qué enmascara rrweb por defecto?

Nada más instalarlo, rrweb enmascara exactamente una cosa: el valor de input[type="password"]. El texto y todos los demás tipos de entrada se graban literalmente, así que los campos de correo, nombre, dirección, número de tarjeta y texto libre salen del navegador con su contenido real salvo que usted lo configure de otro modo.

Dos detalles del código fuente de rrweb convierten ese valor por defecto en una trampa. El primero es que maskInputOptions sustituye el valor por defecto en lugar de fusionarse con él. Pase maskInputOptions: { email: true } porque quiere cubrir los correos y habrá desactivado en silencio el enmascaramiento de contraseñas. La forma segura escribe { password: true, email: true } siempre.

El segundo es la forma del tipo MaskInputOptions. Acepta color, date, datetime-local, email, month, number, range, search, tel, text, time, url, week, textarea, select y password, y no acepta checkbox, radio ni file. Poner maskAllInputs: true se expande a todas las claves de esa lista, así que incluso el ajuste máximo de enmascaramiento de entradas graba qué casillas y botones de radio seleccionó un visitante. En un formulario de admisión médica, la casilla es el dato sensible. FullStory lo resuelve excluyendo en vez de enmascarar: su función 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 qué se diferencian los proveedores de session replay en sus valores de enmascaramiento?

Los proveedores se sitúan en extremos opuestos del mismo juego de herramientas, y el valor por defecto decide cuánto cuesta una regla que se le pasó por alto.

Herramienta	Enmascarado sin configuración	Mecanismo de exclusión
rrweb	Solo input[type="password"]	Ninguno; no existe opción para desenmascarar
PostHog	Todas las entradas (maskAllInputs vale true por defecto); el texto no se enmascara	Clase ph-no-capture
Sentry	Todo el texto (maskAllText: true), todas las entradas, todos los medios (blockAllMedia: true)	.sentry-unmask, .sentry-unblock, ninguna aplicada por defecto
Microsoft Clarity	Números y direcciones de correo en el modo Balanced por defecto; entradas y desplegables en todos los modos	data-clarity-unmask="true"
FullStory con Private by Default	Todos los elementos, capturados enmascarados	.fs-unmask
LogRocket	Nada; inputSanitizer y textSanitizer valen false por defecto	data-public

Sentry expone su postura sin rodeos: "by default, the Session Replay SDK will mask all text content with * and block all media elements." Clarity ofrece el compromiso contrario mediante tres modos, donde Strict enmascara "the entire content", Balanced enmascara "numbers and email addresses" y Relaxed no enmascara nada más allá de las entradas y los desplegables. Dos comportamientos de Clarity no son configurables en absoluto: "Content in the input boxes is masked in all modes and can't be customized" y "The drop-down menus are also masked in all modes." Clarity marca lo que ocultó con ▫ para un dígito, ▪ para una letra y • para el modo Strict.

¿Por qué el texto enmascarado sigue filtrando información?

El texto enmascarado filtra la longitud de lo que sustituyó, porque los grabadores más extendidos ponen un carácter de marcador por cada carácter original. La función de enmascaramiento de rrweb es literalmente text = '*'.repeat(text.length). La función de máscara por defecto de Sentry es (s) => '*'.repeat(s.length). FullStory lo dice de forma explícita: "This placeholder text blob will retain the size, color, and character length of the original text."

La propia documentación de FullStory hace tangible el riesgo para un campo como el saldo de una cuenta: "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 longitud no es el único canal. Los elementos enmascarados siguen grabando interacciones, y por eso FullStory dice a sus clientes sanitarios que excluyan en vez de enmascarar: "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."

La solución para ambos casos es la misma. Devuelva una cadena de longitud fija desde una maskTextFn o maskInputFn propia en lugar de una que trabaje carácter a carácter, y suba todo lo que permita inferencias de enmascarado a bloqueado. La distancia entre reducir la identificabilidad y eliminarla es la diferencia entre seudonimización y anonimización.

¿Qué se les escapa a las reglas de enmascaramiento?

Las reglas de enmascaramiento se aplican a los nodos de texto del DOM y a los valores de las entradas, así que todo lo que lleve datos fuera de esos dos sitios se queda en la grabación. Cada proveedor documenta su propio punto ciego.

• Hojas de estilo. Clarity "doesn't mask content within style sheets or style tags. Hence, it is recommended not to host sensitive content within CSS."
• SVG en línea. Hotjar: "SVGs linked as the source for image elements can be suppressed, but inline SVGs cannot."
• Imágenes en web. FullStory: "Images cannot be masked when capturing data on web sessions. If you wish to hide images from data capture, use .fs-exclude."
• URLs y cargas de red. Una página enmascarada con un número de cuenta en la cadena de consulta lo sigue enviando. PostHog expone maskCapturedNetworkRequestFn; FullStory usa listas de permitidos para los cuerpos de petición y respuesta.
• Propiedades de eventos personalizados. La redacción gobierna el flujo de replay, no los eventos de analítica que envía su propio código.

¿Se puede aplicar el enmascaramiento a grabaciones que ya tiene?

Ningún proveedor puede redactar de forma retroactiva una sesión que ya llegó a sus servidores, y dos lo dicen por escrito. 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."

La cifra de una hora es la parte que los equipos pasan por alto. Añadir una regla después de detectar números de tarjeta en un replay deja hasta una hora más de grabaciones capturándolos, encima de todo lo ya almacenado. Los remedios son borrar las grabaciones afectadas y acortar la retención, lo que convierte la duración de la retención en un control de redacción más que en un ajuste de almacenamiento. También es la razón por la que los demandantes en las demandas por escuchas ilegales por session replay discuten sobre qué se capturó y no sobre qué se ocultó después en la interfaz de reproducción.

¿Conviene enmascararlo todo y desenmascarar, o al revés?

Enmascare todo por defecto y desenmascare lo que haya verificado, porque el modo de fallo de una lista de bloqueo es capturar datos que nunca quiso y el modo de fallo de una lista de permitidos es un replay aburrido. FullStory construyó Private by Default sobre ese razonamiento: "no text is captured or sent outside the user's browser unless it is explicitly allowlisted as safe to capture", de modo que "you won't accidentally capture unwanted data even if you fail to set specific data capture rules."

Aclare la regla de precedencia antes de escribir el primer selector. FullStory resuelve los conflictos a favor de la privacidad: "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 va en sentido contrario con los atributos: data-clarity-unmask="true" desenmascara un nodo y sus hijos y "overrides anything set on the Clarity website." Dos productos, dos respuestas opuestas.

Mantenga las reglas en el código y no en un panel. FullStory llama al enfoque de código primero "a less brittle and more future-proof approach than handling these rules through the UI using CSS selectors", porque un selector escrito en una pantalla de ajustes se rompe en silencio cuando una biblioteca de componentes publica nuevos nombres de clase.

Flowsery funciona sin cookies y graba sesiones sin muestreo. Si todavía está decidiendo qué captura el replay, empiece por qué es el session replay y fije después la política de enmascaramiento, antes de que la primera etiqueta de script entre en producción.

Preguntas frecuentes

¿El enmascaramiento en session replay ocurre antes o después de enviar los datos?

Antes, en todos los productos documentados aquí. Clarity "never captures anything that is masked or sent over the wire", y Hotjar describe la supresión como la eliminación de datos personales "before sending a session from your website's Document Object Model (DOM) to Hotjar". El enmascaramiento aplicado en el momento de la reproducción es un filtro de visualización, no una redacción.

¿maskAllInputs: true cubre todos los campos de formulario en rrweb?

No. Se expande a todas las claves del tipo MaskInputOptions de rrweb, que omite checkbox, radio y file, así que el estado de casillas y botones de radio se sigue grabando. Bloquee esos elementos en su lugar, como hace Form Privacy de FullStory.

¿Puedo desenmascarar un campo dentro de un contenedor enmascarado?

Depende del producto, y rrweb por sí solo no puede. Las opciones de grabación de rrweb no incluyen ninguna clase ni selector para desenmascarar, así que una máscara sobre un padre cubre a todos sus hijos. FullStory y Sentry añaden el desenmascarado por encima, y Sentry entrega .sentry-unmask y .sentry-unblock sin aplicarlos a nada por defecto.

¿Cuál es la diferencia entre enmascarar y bloquear un elemento?

Enmascarar conserva el elemento y sustituye su texto; bloquear elimina el elemento y reproduce un marcador. FullStory traza la línea según el riesgo de inferencia y recomienda la exclusión para datos regulados, para identificadores como números de cuenta bancaria y para cualquier elemento en el que la sola interacción revele algo personal.

¿Las grabaciones enmascaradas siguen contando como datos personales?

Trátelas como datos personales hasta que demuestre lo contrario. Un enmascaramiento que conserva la longitud de los caracteres, las coordenadas de clic y la estructura de los elementos reduce la identificabilidad sin eliminarla, lo que es seudonimización y no anonimización, y los datos seudonimizados siguen dentro del ámbito del RGPD.

¿Cuánto tarda en aplicarse una regla de enmascaramiento recién añadida?

En Clarity la cifra documentada es de hasta una hora, y solo para grabaciones nuevas. Las reglas del lado del cliente en rrweb, Sentry, PostHog y LogRocket surten efecto en la siguiente carga de página que sirva el script actualizado, así que un paquete en caché o un TTL de CDN largo alarga la ventana en la que aún rigen las reglas antiguas.

¿Qué herramienta de session replay enmascara más por defecto?

Sentry tiene el valor por defecto más estricto de las herramientas que cubre esta página: enmascara todo el texto (maskAllText: true), enmascara cada input y bloquea todos los medios (blockAllMedia: true). rrweb está en el extremo opuesto, enmascarando por defecto solo input[type="password"] mientras no configures nada más. Elegir un proveedor sin revisar estos valores por defecto es decidir cuánto queda expuesto antes de escribir una sola regla propia.

¿PostHog enmascara el texto por defecto?

PostHog no enmascara el texto por defecto. Enmascara todos los inputs, porque maskAllInputs viene en true de forma predeterminada, pero los nodos de texto se graban tal cual sin reglas adicionales. La clase ph-no-capture permite sacar elementos concretos de la grabación, que se sustituyen por un bloque del mismo tamaño.

¿Se pueden enmascarar los SVG en línea o las hojas de estilo en session replay?

Las reglas de enmascaramiento se aplican a los nodos de texto del DOM y a los valores de los inputs, así que todo lo que quede fuera de esos dos lugares no queda cubierto. Clarity no enmascara el contenido dentro de hojas de estilo ni de etiquetas style, por lo que recomienda no alojar contenido sensible en CSS. Hotjar señala que los SVG usados como origen de una imagen se pueden suprimir, pero los SVG en línea no.

¿Las reglas de enmascaramiento deben vivir en el código o en un panel de configuración?

Mejor en el código. FullStory describe el enfoque código primero como menos frágil que gestionar las reglas desde la interfaz con selectores CSS, porque un selector definido en una pantalla de configuración se rompe en silencio en cuanto una librería de componentes cambia los nombres de sus clases. Versionar las reglas junto con la aplicación permite publicar y revertir un cambio como cualquier otro código.