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 via un processus appelé "partitionnement de 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 de partitionnement de l'espace de stockage similaires sont également en place ou prévus dans d'autres navigateurs majeurs, comme Firefox et Safari. La proposition de partitionnement de l'espace de stockage sur GitHub est ouverte à la discussion.

Qu'est-ce que le partitionnement de l'espace de 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 de l'espace de stockage, un site peut joindre des données provenant de différents sites pour suivre l'utilisateur sur le Web. De plus, il permet au site intégré d'inférer des états spécifiques sur l'utilisateur sur le site de niveau supérieur à l'aide de techniques de canal auxiliaire telles que les attaques par cassage de chiffrement, les fuites XS et les COSI.

Auparavant, le stockage n'était basé que sur l'origine. Cela signifie que si un iFrame de example.com est intégré à a.com et b.com, il peut en savoir plus sur vos habitudes de navigation sur ces deux sites en stockant et en récupérant un ID à partir de l'espace de stockage. Lorsque le partitionnement du stockage tiers est activé, le stockage de 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 des API de stockage telles que le stockage local 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 de stockage sans partitionnement.
Avant le partitionnement de l'espace de 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 de l'espace de stockage, example.com, lorsqu'il est intégré à b.com, ne peut pas accéder à l'espace de stockage d'example.com lorsqu'il est intégré à a.com.

Partitionnement du stockage sur des iFrames en chaîne

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

Par exemple, A1 contient une iframe pour B, qui contient une iframe pour A2, et A1 et A2 se trouvent sur le même site. Si la partition ne prenait en compte que le site de premier niveau et l'origine du frame actuel, l'iFrame A2 pourrait être traitée par erreur comme "propriétaire", car elle partage un site avec le site de premier niveau (A1), malgré l'iFrame B intersite entre les deux. Cela pourrait exposer A2 à des risques de sécurité tels que le hameçonnage de clics si A2 avait accès à un stockage non partitionné par défaut.

Pour y remédier, Chrome ajoute un "bit d'ancêtre" à la clé de partition de stockage. Ce bit est défini si un document entre l'iFrame actuelle et le site de niveau supérieur provient d'une autre origine (intersite). Dans ce cas, le site B est intersites. Le bit est donc défini pour A2 et son stockage est partitionné à partir d'A1.

Lorsque la chaîne d'iframes ne comprend que des contextes de même site (par exemple, le site A1 contenant A2, qui contient ensuite A3), le bit d'ancêtre ne partitionne plus leur espace de stockage. Dans ce cas, leur espace de stockage reste partagé, avec comme clé leur origine et leur site de premier niveau communs.

Pour les sites qui ont besoin d'un accès non partitionné sur des iFrames en chaîne, Chrome expérimente l'extension de l'API Storage Access pour permettre ce cas d'utilisation. Comme l'API Storage Access nécessite que le site encadré appelle explicitement l'API, cela réduit le risque de hameçonnage par clic.

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

Les API affectées par le partitionnement peuvent être divisées en groupes comme suit:

API Storage

  • Système de quotas
    Le système de quota permet de déterminer la quantité d'espace disque allouée au stockage. Le système de quota gère chaque partition en tant que bucket distinct pour déterminer la quantité d'espace autorisée et quand elle est effacée.
    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 le stockage en cache utilisent le système de quota partitionné.
  • 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 : le stockage local et le stockage de session. Elles ne sont pas gérées par quota, mais elles sont toujours 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 les dossiers de l'appareil une fois que l'utilisateur a accordé l'accès. Le système de fichiers privé d'origine permet à une origine de stocker du contenu privé directement sur le disque. Ce contenu reste accessible aux utilisateurs, mais 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 que IndexedDB et localStorage à l'aide d'un nouveau concept appelé bucket. Les données stockées dans les buckets et les métadonnées associées 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 à effacer les données stockées dans le navigateur de l'utilisateur. Vous pouvez vider le cache, les cookies et l'espace de stockage DOM. L'utilisation de l'en-tête n'efface que l'espace de stockage d'une seule partition.
  • Stockage d'URL de blob
    Une URL de blob permet d'accéder à un blob, un objet contenant des données brutes. Sans partitionnement de l'espace de stockage, une URL de 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ées à la fois à a.com et à b.com, une URL de blob générée dans l'iFrame intégrée à a.com peut être transmise à l'iFrame intégrée à b.com, puis utilisée par celle-ci sans aucune restriction. À partir de Chrome 137 (publié le 27 mai 2025), les URL blob sont partitionnées pour tous les usages, à l'exception des navigations de niveau supérieur. Les cas qui seront désormais bloqués incluent les cas où des URL de blob interpartitions sont utilisées avec fetch() ou comme valeur de l'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 interpartitions, 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 qui lance la navigation ne peut pas obtenir de poignée de fenêtre pour le document d'URL de blob qu'il a ouvert. Dans l'exemple précédent, le partitionnement empêche l'iFrame sur b.com d'extraire le contenu de l'URL du blob, mais il peut toujours le 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 affectent principalement les API qui permettent de découvrir d'autres contextes à l'aide de la diffusion ou du 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 nœuds de calcul de la même origine.
    Nous ne proposons pas de modifier le comportement des postMessage() d'iframe intersites, car la relation entre ces contextes est déjà clairement définie.
  • SharedWorker
    L'API SharedWorker fournit un nœud de calcul auquel on peut accéder dans les contextes de navigation de la même origine.
  • Serrures Web
    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 verrouillage 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. Les sites enregistrent des services workers qui créent des contextes de nœud de calcul pour répondre aux événements. Traditionnellement, ces nœuds de calcul pouvaient communiquer avec n'importe quel contexte de même origine. Toutefois, comme les services workers peuvent modifier le calendrier des requêtes de navigation, ils présentent un risque de fuite d'informations entre les sites, comme le reniflage de l'historique.

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 sur le Web. Dans ce scénario, les pages de l'extension conservent l'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èdent à leur partition de premier niveau, à condition que l'extension dispose des autorisations d'hôte pour eux.

Pour en savoir plus, consultez la documentation de l'extension.

Démonstration: Tester le partitionnement de l'espace de 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émonstration, montrant la sortie d'un navigateur avec partitionnement de l'espace de stockage à gauche et sans partitionnement de l'espace de stockage à droite.

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

  • Lorsque vous accédez au site A dans le contexte de niveau supérieur, 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 le succès ou l'échec de chaque lecture pour indiquer si les données sont partitionnées.

Pour le moment, vous pouvez désactiver le partitionnement de l'espace de stockage dans Chrome à l'aide de l'option de ligne de commande --disable-features=ThirdPartyStoragePartitioning. Remarque: Cet indicateur de ligne de commande est destiné au développement et aux tests. Il est susceptible d'être supprimé ou modifié dans les futures versions de Chrome.

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

Interagir et envoyer des commentaires