Particionamiento del almacenamiento

Para fortalecer la privacidad del usuario y combatir el seguimiento entre sitios de canales laterales, Chrome ahora aísla la mayoría de las APIs de almacenamiento y comunicación en contextos de terceros a través de un proceso llamado partición de almacenamiento.

Estado de implementación

La función se habilitó para todos los usuarios de Chrome 115 y versiones posteriores. También se están implementando o planificando esfuerzos de partición de almacenamiento similares en otros navegadores importantes, como Firefox y Safari. La propuesta de particionamiento de almacenamiento en GitHub está abierta para que se siga analizando.

¿Qué es la partición de almacenamiento?

Para evitar ciertos tipos de seguimiento entre sitios de canales laterales, Chrome particiona las APIs de almacenamiento y comunicaciones en contextos de terceros.

Sin la partición de almacenamiento, un sitio puede unir datos de diferentes sitios para hacer un seguimiento del usuario en la Web. Además, permite que el sitio incorporado infiera estados específicos sobre el usuario en el sitio de nivel superior mediante técnicas de canal lateral, como ataques de sincronización, fugas de XS y COSI.

Históricamente, el almacenamiento se ha claveado solo por origen. Esto significa que, si un iframe de example.com está incorporado en a.com y b.com, podría obtener información sobre tus hábitos de navegación en esos dos sitios almacenando y recuperando correctamente un ID del almacenamiento. Con la partición de almacenamiento de terceros habilitada, el almacenamiento de example.com existe en dos particiones diferentes, una para a.com y la otra para b.com.

En general, la partición significa que todos los contextos que comparten el mismo origen ya no pueden acceder a los datos escritos por las APIs de almacenamiento, como Local Storage y IndexedDB, dentro de un iframe. En cambio, esos datos ahora están aislados y solo están disponibles para los contextos que comparten el mismo origen y el mismo sitio de nivel superior.

Antes

APIs de almacenamiento sin particiones
Antes de la partición de almacenamiento, example.com puede escribir datos cuando se incorpora en a.com y, luego, leerlos cuando se incorpora en b.com.

Después

APIs de Storage con particiones
Después de la partición del almacenamiento, example.com, cuando está incorporado en b.com, no puede acceder al almacenamiento de example.com cuando está incorporado en a.com.

Partición de almacenamiento en iframes encadenados

La complejidad de la partición de almacenamiento aumenta significativamente cuando se anidan iframes, en particular, cuando el mismo origen aparece varias veces dentro de la cadena.

Por ejemplo, A1 contiene un iframe para B que contiene un iframe para A2, y A1 y A2 están en el mismo sitio. Si la partición solo considerara el sitio de nivel superior y el origen del marco actual, el iframe A2 podría considerarse erróneamente como "propio" porque comparte un sitio con el de nivel superior (A1), a pesar del iframe B entre sitios. Esto podría exponer a A2 a riesgos de seguridad, como el robo de clics, si A2 tuviera acceso al almacenamiento sin particionar de forma predeterminada.

Para abordar esto, Chrome agrega un "bit de ancestro" a la clave de partición de almacenamiento. Este bit se establece si algún documento entre el iframe actual y el sitio de nivel superior proviene de un origen diferente (entre sitios). En este caso, el sitio B es multisitio, por lo que el bit se establecería para A2 y su almacenamiento se particionaría desde A1.

Cuando la cadena de iframes consta únicamente de contextos del mismo sitio (por ejemplo, el sitio A1 que contiene A2, que luego contiene A3), el bit de ancestro no particionará más su almacenamiento. En esos casos, su almacenamiento sigue siendo compartido, con clave de origen común y sitio de nivel superior.

En el caso de los sitios que necesitan acceso sin particionar en iframes encadenados, Chrome está experimentando con la extensión de la API de Storage Access para habilitar este caso de uso. Como la API de Storage Access requiere que el sitio enmarcado invoque la API de forma explícita, esto mitiga el riesgo de ataque de suplantación de clics.

Cambios en la API debido al particionamiento

Las APIs afectadas por el particionamiento se pueden dividir en los siguientes grupos:

APIs de Storage

  • Sistema de cuotas
    El sistema de cuotas se usa para determinar cuánto espacio en disco se asigna para el almacenamiento. El sistema de cuotas administra cada partición como un bucket independiente para determinar cuánto espacio se permite y cuándo se borra.
    El método navigator.storage.estimate() ahora proporciona información específica de la partición de almacenamiento. Las APIs exclusivas de Chrome, como window.webkitStorageInfo y navigator.webkitTemporaryStorage, dejaron de estar disponibles.
    IndexedDB y el almacenamiento en caché usan el sistema de cuotas particionadas.
  • API de Web Storage
    La API de Web Storage proporciona mecanismos a través de los cuales los navegadores pueden almacenar pares clave-valor. Existen dos mecanismos: el almacenamiento local y el almacenamiento de la sesión. No se administran con cuotas, pero aún se particionan.
  • Sistema de archivos privados de Origin
    La API de File System Access permite que un sitio lea o guarde cambios directamente en archivos y carpetas del dispositivo después de que el usuario otorga acceso. El sistema de archivos privados de Origin permite que un origen almacene contenido privado directamente en el disco. Los usuarios pueden acceder a este contenido, pero ahora está particionado.
  • API de Storage Bucket
    La API de Storage Bucket se está desarrollando para Storage Standard, que consolida varias APIs de almacenamiento, como IndexedDB y localStorage, con un nuevo concepto llamado buckets. Los datos almacenados en los buckets y los metadatos asociados con ellos se particionan.
  • Encabezado Clear-Site-Data
    Incluir el encabezado Clear-Site-Data en la respuesta permite que un servidor solicite borrar los datos almacenados en el navegador del usuario. Se pueden borrar la caché, las cookies y el almacenamiento DOM. El uso del encabezado solo borra el almacenamiento dentro de una partición.
  • Almacén de URLs de BLOB
    Una URL de blob proporciona acceso a un blob, un objeto que contiene datos sin procesar. Sin la partición de almacenamiento, una URL de blob generada en un iframe de terceros en un sitio se puede usar en un iframe del mismo origen incorporado en otro sitio. Por ejemplo, si los iframes de example.com están incorporados en a.com y b.com, una URL de blob generada en el iframe incorporado en a.com se puede pasar al iframe incorporado en b.com y, luego, usarlo sin restricciones. A partir de Chrome 137 (lanzado el 27 de mayo de 2025), las URLs de BLOB se particionan para todos los usos, excepto las navegaciones de nivel superior. Entre los casos que ahora se bloquearán, se incluyen los que se producen cuando se usan URLs de objetos blob de partición cruzada con fetch() o como el valor del atributo src para varios elementos HTML. No se bloquearán las navegaciones de nivel superior, como llamar a window.open() o hacer clic en un vínculo con target='_blank', a las URLs de BLOB si son de partición cruzada, pero se aplicará noopener si el sitio de la URL de BLOB es de otro sitio del sitio de nivel superior de la página que inicia la navegación. Si se aplica noopener, se impedirá que el documento que inicia la navegación obtenga un identificador de ventana para el documento de URL de blob que abrió. En el ejemplo anterior, el particionamiento evitará que el iframe en b.com recupere el contenido de la URL del blob, pero aún podrá window.open().

APIs de comunicación

Junto con las APIs de almacenamiento, también se particionan las APIs de comunicación que permiten que un contexto se comunique a través de los límites de origen. Los cambios afectan principalmente a las APIs que permiten el descubrimiento de otros contextos mediante la transmisión o la reunión del mismo origen.

Debido a la partición, las siguientes APIs de comunicación evitan que los iframes de terceros intercambien datos con sus contextos de origen:

  • Canal de transmisión
    La API de Broadcast Channel permite la comunicación entre contextos de navegación (ventanas, pestañas o iframes) y trabajadores del mismo origen.
    No se propone cambiar el comportamiento del iframe entre sitios postMessage(), ya que la relación entre esos contextos ya está claramente definida.
  • SharedWorker
    La API de SharedWorker proporciona un trabajador al que se puede acceder en todos los contextos de navegación del mismo origen.
  • Bloqueos web
    La API de Web Locks permite que el código que se ejecuta en una pestaña o un trabajador del mismo origen adquiera un bloqueo para un recurso compartido mientras se realiza algún trabajo.

API de Service Worker

La API de Service Worker permite que los sitios realicen tareas en segundo plano. Los sitios registran trabajadores del servicio que crean contextos de trabajadores nuevos para responder a eventos. Tradicionalmente, estos trabajadores podían comunicarse con cualquier contexto de origen. Sin embargo, como los service workers pueden alterar el tiempo de las solicitudes de navegación, representan un riesgo de filtraciones de información entre sitios, como el espionaje de historial.

Por este motivo, los trabajadores del servicio registrados desde un contexto de terceros ahora se particionan.

APIs de Extension

Las extensiones son programas que permiten a los usuarios personalizar su experiencia de navegación.

Las páginas de extensión (páginas con un esquema chrome-extension://) se pueden incorporar en sitios de la Web. En este caso, las páginas de la extensión siguen teniendo acceso a su partición de nivel superior. Las extensiones también pueden incorporar otros sitios. Cuando lo hacen, esos sitios incorporados acceden a su partición de nivel superior, siempre que la extensión tenga permisos de host para ellos.

Para obtener más información, consulta los documentos de la extensión.

Demostración: Prueba la partición de almacenamiento

Sitio de demostración: https://storage-partitioning-demo-site-a.glitch.me/

Sitio de demostración que muestra marcas verdes a la izquierda y cruces rojas a la derecha.
Captura de pantalla de la demostración, que muestra el resultado de un navegador con particiones de almacenamiento a la izquierda y sin particiones de almacenamiento a la derecha.

En la demostración, se usan dos sitios: el sitio A y el sitio B.

  • Cuando visitas el sitio A en el contexto de nivel superior, se establecen datos con varios métodos de almacenamiento.
  • El sitio B incorpora una página del sitio A y esa incorporación intenta leer las opciones de almacenamiento establecidas anteriormente.
  • Cuando el sitio A está incorporado en el sitio B, no tiene acceso a esos datos cuando el almacenamiento está particionado, por lo que las operaciones de lectura fallan.
  • La demostración usa el éxito o el error de cada operación de lectura para mostrar si los datos están particionados.

Por ahora, puedes desactivar la partición de almacenamiento en Chrome con el interruptor de línea de comandos --disable-features=ThirdPartyStoragePartitioning. Nota: Este interruptor de línea de comandos está diseñado para fines de desarrollo y prueba, y es posible que se quite o cambie en versiones futuras de Chrome.

También puedes probar otros navegadores de la misma manera para ver su estado de partición.

Interactúa y comparte comentarios