Storage Partitioning

Pour renforcer la confidentialité des utilisateurs et lutter contre le suivi intersites côté canal, Chrome isole désormais la plupart des API de stockage et de communication dans des contextes tiers grâce à un processus appelé "partitionnement du stockage".

État de l'implémentation

Cette fonctionnalité a été activée pour tous les utilisateurs de Chrome 115 et versions ultérieures. Des efforts similaires de partitionnement du stockage sont également en place ou prévus dans d'autres navigateurs majeurs comme Firefox et Safari. La proposition de partitionnement du stockage sur GitHub est ouverte à la discussion.

Qu'est-ce que le partitionnement du stockage ?

Pour empêcher certains types de suivi intersites côté canal, Chrome partitionne les API de stockage et de communication dans des contextes tiers.

Sans partitionnement du stockage, un site peut joindre des données provenant de différents sites pour suivre l'utilisateur sur le Web. Il permet également au site intégré d'inférer des états spécifiques sur l'utilisateur dans le site de premier niveau à l'aide de techniques de canal auxiliaire telles que les attaques temporelles, les XS-Leaks et COSI.

Historiquement, le stockage n'était indexé que par origine. Cela signifie que si un iFrame de example.com est intégré à a.com et b.com, il peut en apprendre davantage sur vos habitudes de navigation sur ces deux sites en stockant et en récupérant un ID à partir du stockage. Lorsque le partitionnement du stockage tiers est activé, le stockage pour example.com existe dans deux partitions différentes, l'une pour a.com et l'autre pour b.com.

En général, le partitionnement signifie que les données écrites par les API de stockage telles que Local Storage et IndexedDB dans un iFrame ne sont plus accessibles par tous les contextes partageant la même origine. Ces données sont désormais isolées et ne sont disponibles que pour les contextes qui partagent à la fois la même origine et le même site de premier niveau.

Avant

API Storage sans partitionnement.
Avant le partitionnement du stockage, example.com peut écrire des données lorsqu'il est intégré à a.com, puis les lire lorsqu'il est intégré à b.com.

Après

API Storage avec partitionnement.
Après le partitionnement du stockage, example.com, lorsqu'il est intégré à b.com, ne peut pas accéder au stockage d'example.com lorsqu'il est intégré à a.com.

Partitionnement du stockage sur les iFrames chaînés

La complexité du partitionnement du stockage augmente considérablement lorsque les iFrames sont imbriqués, en particulier lorsque la même origine apparaît plusieurs fois dans la chaîne.

Par exemple, A1 contient un iFrame pour B qui contient un iFrame pour A2, et A1 et A2 se trouvent sur le même site. Si le partitionnement ne tient compte que du site de premier niveau et de l'origine du frame actuel, l 'iframe A2 peut être traité à tort comme un iframe propriétaire, car il partage un site avec le site de premier niveau (A1), malgré l'iframe B multisite intermédiaire. Cela pourrait exposer A2 à des risques de sécurité tels que le détournement de clic si A2 avait accès au stockage non partitionné par défaut.

Pour résoudre ce problème, Chrome ajoute un bit d'ancêtre à la clé de partition de stockage. Ce bit est défini si un document entre l'iFrame actuel et le site de niveau supérieur provient d'une origine différente (intersite). Dans ce cas, le site B est multisite. Le bit est donc défini pour A2 et son stockage est partitionné à partir de A1.

Lorsque la chaîne d'iframe se compose uniquement de contextes de même site (par exemple, le site A1 contenant A2, qui contient ensuite A3), le bit ancêtre ne partitionne pas davantage leur stockage. Dans ce cas, leur stockage reste partagé, avec pour clé leur origine commune et leur site de premier niveau.

Pour les sites qui ont besoin d'un accès non partitionné aux iFrames en chaîne, Chrome teste l'extension de l'API Storage Access pour permettre ce cas d'utilisation. Comme l'API Storage Access exige que le site encadré invoque explicitement l'API, cela atténue le risque de clickjacking.

Modifications apportées à l'API en raison du partitionnement

Les API concernées par le partitionnement peuvent être divisées en plusieurs groupes :

API Storage

  • Système de quotas
    Le système de quotas permet de déterminer la quantité d'espace disque allouée au stockage. Le système de quotas gère chaque partition comme un bucket distinct pour déterminer l'espace autorisé et le moment où il est libéré.
    La méthode navigator.storage.estimate() fournit désormais des informations spécifiques à la partition de stockage. Les API Chrome uniquement, telles que window.webkitStorageInfo et navigator.webkitTemporaryStorage, ont été abandonnées.
    IndexedDB et Cache Storage utilisent le système de quotas partitionnés.
  • API Web Storage
    L'API Web Storage fournit des mécanismes permettant aux navigateurs de stocker des paires clé-valeur. Il existe deux mécanismes : Stockage local et Stockage de session. Elles ne sont pas gérées par des quotas, mais sont tout de même partitionnées.
  • Origin Private File System
     L'API File System Access permet à un site de lire ou d'enregistrer des modifications directement dans les fichiers et dossiers de l'appareil une fois que l'utilisateur a accordé l'accès. Le système de fichiers privés d'origine permet à une origine de stocker du contenu privé directement sur le disque. Ce contenu reste accessible aux utilisateurs, mais il est désormais partitionné.
  • API Storage Bucket
    L'API Storage Bucket est en cours de développement pour Storage Standard, qui consolide diverses API de stockage telles qu'IndexedDB et localStorage en utilisant un nouveau concept appelé "buckets". Les données stockées dans les buckets et les métadonnées associées aux buckets sont partitionnées.
  • En-tête Clear-Site-Data
     L'inclusion de l'en-tête Clear-Site-Data dans la réponse permet à un serveur de demander l'effacement des données stockées dans le navigateur de l'utilisateur. Vous pouvez vider le cache et effacer les cookies et le stockage DOM. L'utilisation de l'en-tête efface uniquement le stockage d'une partition.
  • Stockage des URL blob
    Une URL Blob permet d'accéder à un blob, un objet contenant des données brutes. Sans partitionnement du stockage, une URL blob générée dans un iFrame tiers sur un site peut être utilisée dans un iFrame de même origine intégré à un autre site. Par exemple, si des iFrames example.com sont intégrés à la fois sur a.com et b.com, une URL blob générée dans l'iFrame intégré sur a.com peut être transmise à l'iFrame intégré sur b.com, puis utilisée par celui-ci sans aucune restriction. À partir de Chrome 137 (sorti le 27 mai 2025), les URL blob sont partitionnées pour toutes les utilisations, à l'exception des navigations de niveau supérieur. Les cas qui seront désormais bloqués incluent l'utilisation d'URL de blobs inter-partitions avec fetch() ou comme valeur d'attribut src pour divers éléments HTML. Les navigations de niveau supérieur, telles que l'appel de window.open() ou le clic sur un lien avec target='_blank', vers des URL blob ne seront pas bloquées si elles sont inter-partition, mais noopener sera appliqué si le site de l'URL blob est intersite par rapport au site de premier niveau de la page qui lance la navigation. Si noopener est appliqué, le document à l'origine de la navigation ne pourra pas obtenir de handle de fenêtre pour le document d'URL blob qu'il a ouvert. Dans l'exemple précédent, le partitionnement empêchera l'iFrame sur b.com de récupérer le contenu de l'URL du blob, mais il pourra toujours window.open().

API de communication

En plus des API de stockage, les API de communication qui permettent à un contexte de communiquer au-delà des limites d'origine sont également partitionnées. Les modifications concernent principalement les API qui permettent de découvrir d'autres contextes à l'aide de la diffusion ou du point de rendez-vous de même origine.

En raison du partitionnement, les API de communication suivantes empêchent les iFrames tiers d'échanger des données avec leurs contextes de même origine :

  • Canal de diffusion
    L'API Broadcast Channel permet la communication entre les contextes de navigation (fenêtres, onglets ou iFrames) et les workers de la même origine.
    Il n'est pas proposé de modifier le comportement de l'iframe postMessage() multisite, car la relation entre ces contextes est déjà clairement définie.
  • SharedWorker
    L'API SharedWorker fournit un worker accessible dans les contextes de navigation de la même origine.
  • Web Locks
    L'API Web Locks permet au code exécuté dans un onglet ou un nœud de calcul de la même origine d'acquérir un verrou pour une ressource partagée pendant l'exécution d'une tâche.

API Service Worker

L'API Service Worker permet aux sites d'effectuer des tâches en arrière-plan. Sites enregistre les service workers qui créent de nouveaux contextes de worker pour répondre aux événements. Traditionnellement, ces workers pouvaient communiquer avec n'importe quel contexte de même origine. Toutefois, comme les service workers peuvent modifier le timing des requêtes de navigation, ils présentent un risque de fuite d'informations multisite, comme l'historique sniffing.

C'est pourquoi les Service Workers enregistrés à partir d'un contexte tiers sont désormais partitionnés.

API d'extension

Les extensions sont des programmes qui permettent aux utilisateurs de personnaliser leur expérience de navigation.

Les pages d'extension (pages avec un schéma chrome-extension://) peuvent être intégrées sur des sites Web. Dans ce scénario, les pages d'extension continuent d'avoir accès à leur partition de premier niveau. Les extensions peuvent également intégrer d'autres sites. Dans ce cas, ces sites intégrés accéderont à leur partition de premier niveau, à condition que l'extension dispose des autorisations d'hôte pour eux.

Pour en savoir plus, consultez la documentation sur les extensions.

Démonstration : tester le partitionnement du stockage

Site de démonstration : https://storage-partitioning-demo-site-a.glitch.me/

Site de démonstration affichant des coches vertes à gauche et des croix rouges à droite.
Capture d'écran de la démo, montrant la sortie pour un navigateur avec partitionnement du stockage à gauche et sans partitionnement du stockage à droite.

La démo utilise deux sites : le site A et le site B.

  • Lorsque vous accédez au site A dans le contexte de premier niveau, il définit des données à l'aide de différentes méthodes de stockage.
  • Le site B intègre une page du site A, et cette intégration tente de lire les options de stockage définies précédemment.
  • Lorsque le site A est intégré au site B, il n'a pas accès à ces données lorsque le stockage est partitionné. Les lectures échouent donc.
  • La démonstration utilise la réussite ou l'échec de chaque lecture pour indiquer si les données sont partitionnées.

Pour l'instant, vous pouvez désactiver le partitionnement du stockage dans Chrome à l'aide du commutateur de ligne de commande --disable-features=ThirdPartyStoragePartitioning. Remarque : Ce commutateur de ligne de commande est destiné au développement et aux tests. Il pourra être supprimé ou modifié dans les prochaines versions de Chrome.

Vous pouvez également tester d'autres navigateurs de la même manière pour connaître leur état de partitionnement.

Demander un délai de migration supplémentaire

Pour les sites ayant besoin de plus de temps pour migrer leurs dépendances, la période d'évaluation de l'abandon DisableThirdPartyStoragePartitioning3 est désormais prolongée. Cette évaluation offre un mécanisme temporaire permettant aux sites de premier niveau d'activer le stockage non partitionné, les service workers et les API de communication pour les contextes tiers intégrés à leurs pages.

Pour en savoir plus, consultez Renouvellement de la période d'essai de l'abandon de Storage Partitioning.

Interagir et envoyer des commentaires