¿Pueden las webs leer tu portapapeles? Prueba las dos vías

Copiaste una contraseña, abriste una web y apareció una solicitud para leer tu portapapeles. ¿Qué entregarías exactamente al pulsar Permitir? Y si no aparece ninguna solicitud, ¿significa que la página no puede leer nada?

Hay dos vías de acceso. Al pegar en una página, le entregas los datos de ese pegado. Una API del navegador permite leer el portapapeles sin pegar, siempre que se cumplan las reglas de acceso del navegador. Confundir ambas vías lleva tanto a la respuesta tranquilizadora pero falsa, «las webs no pueden leer tu portapapeles», como a la alarmista, «todas las pestañas abiertas ven tus contraseñas».

Pegar ya es entregar datos

Pulsa Ctrl+V o Command+V en un campo de texto y el navegador dispara un evento paste. Un manejador puede llamar a event.clipboardData.getData('text/plain') antes de que el texto aparezca en el campo. Ese pegado iniciado por ti no necesita un diálogo adicional de permiso para el portapapeles. Acabas de indicarle al navegador dónde colocar los datos.

El evento se propaga por el documento, así que el manejador no tiene por qué estar en ese campo concreto. Una página también puede cancelar la inserción predeterminada. Que el cuadro siga vacío después de pegar no demuestra que la página no haya recibido nada.

Pruébalo aquí. Selecciona y copia el texto de ejemplo; después, pégalo en el cuadro vacío. La demo cuenta la longitud del texto y enumera los formatos que expone el evento. Descarta el texto pegado en vez de insertarlo. Este componente no envía ni guarda los datos de ninguna de las dos pruebas.

Una celda de una hoja de cálculo o un párrafo con formato pueden aportar algo más que texto plano. El portapapeles puede contener varias representaciones del mismo elemento, como text/plain y text/html. Una página puede recibir los formatos que el navegador exponga para ese pegado, además de los caracteres que esperabas ver. Nuestra demo enumera los nombres de los formatos; no renderiza HTML pegado ni abre archivos pegados.

¿Puede una web leer el portapapeles sin que pegues nada?

Sí, cuando el navegador permite una lectura directa. navigator.clipboard.readText() solicita el texto que contiene el portapapeles en ese momento. read() también puede solicitar formatos compatibles que no sean texto. Estos métodos pertenecen a la API asíncrona del portapapeles, limitada a contextos seguros como HTTPS. Una conexión segura es un requisito previo, no un permiso general para recopilar tus datos.

Pulsa el botón de lectura de la demo solo después de copiar el ejemplo inofensivo. Es una solicitud real a la API, así que el navegador puede mostrar su propio diálogo de permiso o una opción Pegar. La página indica si la solicitud tuvo éxito y la longitud del texto devuelto. Si se rechaza, no muestra una insignia verde de «navegador seguro»: el rechazo describe esta solicitud concreta, con ese estado de foco y esos permisos.

La especificación del portapapeles distingue un pegado real del usuario de un script que emite un evento llamado paste. Un script no puede fabricar un evento de pegado de confianza para acceder al portapapeles del sistema. Por eso la primera prueba necesita que pegues y la segunda necesita una lectura autorizada por el navegador.

Chrome puede recordar el permiso; Safari y Firefox funcionan de otra forma

En los navegadores basados en Chromium, incluidos Chrome y Edge, un documento que tenga el foco puede solicitar el permiso clipboard-read. Si ya está concedido, una lectura que cumpla los demás requisitos puede completarse sin otra solicitud. «Esta vez no me preguntó» no demuestra que nunca se haya concedido acceso. Revisa los permisos que ya tiene el sitio.

Firefox y Safari no implementan ese mismo permiso persistente clipboard-read. Su vía de lectura directa requiere una interacción reciente del usuario y puede mostrar una opción temporal para pegar. Leer contenido copiado desde el mismo origen puede evitar esa confirmación. Por eso, probar solo con texto copiado en la propia página de prueba puede dar una idea equivocada de lo que ocurre con texto copiado en otra aplicación.

Para una segunda prueba, escribe una frase inofensiva en un editor de texto local, cópiala allí, vuelve aquí y solicita otra lectura. Compara lo que muestra el navegador, además del número final. MDN documenta las diferencias entre navegadores; WebKit explica su diseño de acceso al portapapeles. Los marcos incrustados y las políticas del navegador pueden imponer restricciones adicionales, así que prueba con el navegador que usas habitualmente.

¿Un botón Copiar lee lo que había antes?

No tiene por qué. Un botón que usa navigator.clipboard.writeText() escribe el texto de la página en el portapapeles. Ese método no devuelve primero el contenido anterior. Leer y escribir son operaciones distintas con reglas de acceso diferentes, como explica la guía de Google sobre la API asíncrona del portapapeles.

Una página también puede manejar el evento copy, elegir qué se coloca en el portapapeles y cancelar la copia predeterminada. La API del evento copy no entrega el contenido anterior del portapapeles al manejador. Pero sí puede leer el texto seleccionado en su propio documento. Copiar una frase de una página es una interacción observable, como muestra nuestra demo de cambios de pestaña y actividad en la página.

Esto también explica por qué el botón Copiar de un sitio no garantiza que el texto copiado coincida con el visible. Revisa los comandos pegados antes de ejecutarlos. El paso peligroso es ejecutar lo que haya llegado, no la existencia de un botón Copiar.

¿Pueden las webs ver el historial del portapapeles?

La API web habitual del portapapeles no tiene ningún método para enumerar el historial del portapapeles de tu sistema operativo. Una lectura autorizada accede al contenido actual, no a un archivo consultable de todo lo que copiaste la semana pasada. Los gestores de portapapeles, las extensiones del navegador y las aplicaciones nativas tienen sus propios modelos de acceso; el comportamiento de una aplicación móvil no demuestra lo que puede hacer una página web normal.

Ese límite no borra los datos que ya entregaste. Un sitio que recibió texto puede conservar su propia copia. Sustituir el contenido del portapapeles, cerrar la pestaña o restablecer el permiso después no elimina la copia que el sitio ya haya guardado. Del mismo modo, el botón Borrar resultados de arriba limpia la pantalla de esta demo; no vacía el portapapeles del sistema ni revoca un permiso del navegador.

Cierra la vía de acceso que abriste

En Chrome de escritorio, abre Configuración, Privacidad y seguridad, Configuración de sitios y busca Portapapeles. Revisa los sitios permitidos y retira los accesos que ya no necesites. También puedes abrir los controles del sitio actual junto a la barra de direcciones y revisar su configuración. La guía de permisos de Google documenta estos controles. Bloquear las lecturas directas no impide que una página reciba lo que tú pegas en ella deliberadamente.

En el trabajo diario, pega solo en un destino al que quieras entregar los datos. Usa ejemplos inofensivos para comprobar los permisos. Si quieres saber qué averigua una página sin que interactúes con ella, compara esta prueba con el fingerprinting de fuentes o la lectura del renderizador de WebGL: son otras vías de recopilación, y el rechazo de una lectura del portapapeles no dice nada sobre ellas.

Si gestionas cuentas de clientes en perfiles separados, una herramienta como Incogniton puede ayudarte a organizar ese trabajo. Aun así, trata cada pegado como una transferencia deliberada a la página receptora. Separar los perfiles no justifica pegar un secreto de un cliente en la cuenta equivocada.

Copia el ejemplo, compara los dos resultados y revisa cualquier permiso que hayas concedido durante la prueba. Después, ejecuta el análisis completo para inspeccionar las señales del navegador que no dependen de un pegado.