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 en Chrome 115 y versiones posteriores. También se están realizando o planificando esfuerzos similares de partición del almacenamiento en otros navegadores importantes, como Firefox y Safari. La propuesta de partición de almacenamiento en GitHub está abierta para seguir debatiendo.

¿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. También permite que el sitio incorporado infiera estados específicos sobre el usuario en el sitio de nivel superior con técnicas de canales laterales, como ataques de sincronización, XS-Leaks y COSI.

Históricamente, el almacenamiento solo se indexó por origen. Esto significa que, si se incorpora un iframe de example.com 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 para example.com existe en dos particiones diferentes, una para a.com y la otra para b.com.

En general, la partición significa que los datos escritos por las APIs de almacenamiento, como Local Storage y IndexedDB, dentro de un iframe ya no son accesibles para todos los contextos que comparten el mismo origen. 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

Son APIs de Storage sin partición.
Antes de la partición del 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 se incorpora en b.com, no puede acceder al almacenamiento de example.com cuando se incorpora en a.com.

Partición de almacenamiento en iframes encadenados

La complejidad de la partición de almacenamiento aumenta significativamente cuando los iframes están anidados, en especial cuando el mismo origen aparece varias veces en la cadena.

Por ejemplo, A1 contiene un iframe para B, que contiene un iframe para A2, y tanto A1 como A2 están en el mismo sitio. Si la partición solo considera el sitio de nivel superior y el origen del marco actual, es posible que el iframe A2 se trate erróneamente como "propio" porque comparte un sitio con el nivel superior (A1), a pesar del iframe B de sitios cruzados que se encuentra en el medio. Esto podría exponer A2 a riesgos de seguridad, como el clickjacking, si A2 tuviera acceso al almacenamiento sin particiones de forma predeterminada.

Para abordar este problema, Chrome agrega un "bit principal" 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 de origen cruzado, por lo que el bit se establecería para A2 y su almacenamiento se particionaría desde A1.

Cuando la cadena de iframe 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 y se indexa con su origen común y su sitio de nivel superior.

En el caso de los sitios que necesitan acceso sin particionar en varios elementos iframe 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, se mitiga el riesgo de clickjacking.

Cambios en la API debido a la partición

Las APIs afectadas por la partición 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 Cache storage usan el sistema de cuotas particionadas.
  • API de Web Storage
    La API de Web Storage proporciona mecanismos por los que los navegadores pueden almacenar pares clave-valor. Existen dos mecanismos: almacenamiento local y almacenamiento de sesión. No se administran con cuotas, pero sí se particionan.
  • Origin Private File System
    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. Origin Private File System permite que un origen almacene contenido privado directamente en el disco. Este contenido sigue siendo accesible para los usuarios, 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 a 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. Usar el 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, se puede usar una URL de BLOB generada en un iframe de terceros en un sitio 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, se puede pasar una URL de BLOB generada en el iframe incorporado en a.com al iframe incorporado en b.com y, luego, usarla 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. Los casos que ahora se bloquearán incluyen cuando se usan URLs de BLOB entre particiones con fetch() o como el valor del atributo src para varios elementos HTML. Las navegaciones de nivel superior, como llamar a window.open() o hacer clic en un vínculo con target='_blank', a URLs de BLOB no se bloquearán si son entre particiones, 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 controlador de ventana para el documento de URL de Blob que abrió. En el ejemplo anterior, la partición 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 a través de la transmisión o el encuentro de mismo origen.

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

  • Canal de difusió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 postMessage() de sitios cruzados, 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.
  • Web Locks
    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 service workers que crean nuevos contextos de trabajadores para responder a los eventos. Tradicionalmente, estos trabajadores podían comunicarse con cualquier contexto del mismo origen. Sin embargo, dado que 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 rastreo del historial.

Por este motivo, ahora se particionan los Service Workers registrados desde un contexto de terceros.

APIs de extensiones

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

Las páginas de extensiones (páginas con un esquema chrome-extension://) se pueden incorporar en sitios de toda la Web. En este caso, las páginas de la extensión seguirán teniendo acceso a su partición de nivel superior. Las extensiones también pueden incorporar otros sitios. Cuando lo hacen, esos sitios incorporados accederán 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 la documentación de la extensión.

Demostración: Prueba de la partición de almacenamiento

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

Sitio de demostración que muestra marcas de verificación verdes a la izquierda y cruces rojas a la derecha.
Captura de pantalla de la demostración, en la que se muestra el resultado de un navegador con partición de almacenamiento a la izquierda y sin partición 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 lecturas fallan.
  • En la demostración, se usa el éxito o el fracaso de cada lectura para mostrar si los datos están particionados.

Por el momento, puedes desactivar la partición de almacenamiento en Chrome con el interruptor de línea de comandos --disable-features=ThirdPartyStoragePartitioning. Nota: Este parámetro de la 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.

Solicita tiempo adicional para la migración

Para los sitios que necesitan tiempo adicional para migrar sus dependencias, se extendió la prueba de baja de DisableThirdPartyStoragePartitioning3. Esta prueba ofrece un mecanismo temporal para que los sitios de nivel superior habiliten el almacenamiento sin particiones, los service workers y las APIs de comunicación para los contextos de terceros incorporados en sus páginas.

Visita Renovación de la prueba de baja de la partición de almacenamiento para obtener más información.

Interactúa y comparte comentarios