Particionamento de armazenamento

Para reforçar a privacidade do usuário e combater o rastreamento entre sites de canal lateral, o Chrome agora isola a maioria das APIs de armazenamento e comunicação em contextos de terceiros por um processo chamado particionamento de armazenamento.

Status da implementação

O recurso foi ativado para todos os usuários do Chrome 115 e versões mais recentes. Esforços semelhantes de particionamento de armazenamento também estão em vigor ou planejados em outros navegadores importantes, como Firefox e Safari. A proposta de particionamento de armazenamento no GitHub está aberta para mais discussões.

O que é partição de armazenamento?

Para evitar determinados tipos de rastreamento entre sites de canal lateral, o Chrome particiona as APIs de armazenamento e comunicação em contextos de terceiros.

Sem o particionamento de armazenamento, um site pode combinar dados de diferentes sites para rastrear o usuário na Web. Além disso, ele permite que o site incorporado infira estados específicos sobre o usuário no site de nível superior usando técnicas de canal lateral, como ataques de tempo, XS-Leaks e COSI.

Antes, o armazenamento era identificado apenas pela origem. Isso significa que, se um iframe de example.com estiver incorporado em a.com e b.com, ele poderá aprender sobre seus hábitos de navegação nesses dois sites armazenando e recuperando um ID do armazenamento. Com o particionamento de armazenamento de terceiros ativado, o armazenamento de example.com existe em duas partições diferentes, uma para a.com e outra para b.com.

Em geral, o particionamento significa que os dados gravados por APIs de armazenamento, como o armazenamento local e o IndexedDB, em um iframe não podem mais ser acessados por todos os contextos que compartilham a mesma origem. Em vez disso, esses dados agora são isolados e só estão disponíveis para contextos que compartilham a mesma origem e o mesmo site de nível superior.

Antes

APIs de armazenamento sem particionamento.
Antes do particionamento de armazenamento, o site example.com podia gravar dados quando incorporado em a.com e ler quando incorporado em b.com.

Depois

APIs de armazenamento com particionamento.
Depois do particionamento de armazenamento, o site example.com, quando incorporado em b.com, não pode acessar o armazenamento de example.com quando incorporado em a.com.

Particionamento de armazenamento em iframes encadeados

A complexidade do particionamento de armazenamento aumenta significativamente quando os iframes são aninhados, principalmente quando a mesma origem aparece várias vezes na cadeia.

Por exemplo, A1 contém um iframe para B, que contém um iframe para A2, e A1 e A2 estão no mesmo site. Se o particionamento considerar apenas o site de nível superior e a origem do frame atual, o iframe A2 poderá ser tratado erroneamente como "primário" porque compartilha um site com o nível superior (A1), apesar do iframe entre sites B. Isso poderia expor o A2 a riscos de segurança, como clickjacking, se ele tivesse acesso ao armazenamento não particionado por padrão.

Para resolver isso, o Chrome adiciona um bit ancestral à chave de partição de armazenamento. Esse bit é definido se algum documento entre o iframe atual e o site de nível superior for de uma origem diferente (entre sites). Nesse caso, o site B é entre sites, então o bit seria definido para A2, e o armazenamento seria particionado de A1.

Quando a cadeia de iframe consiste apenas em contextos do mesmo site (por exemplo, Site A1 contendo A2, que então contém A3), o bit ancestral não particiona ainda mais o armazenamento. Nesses casos, o armazenamento permanece compartilhado, com chave pela origem comum e pelo site de nível superior.

Para sites que precisam de acesso não particionado em iframes encadeados, o Chrome está testando a extensão da API Storage Access para ativar esse caso de uso. Como a API Storage Access exige que o site em frame invoque explicitamente a API, isso reduz o risco de clickjacking.

Mudanças na API devido ao particionamento

As APIs afetadas pelo particionamento podem ser divididas nos seguintes grupos:

APIs de armazenamento

  • Sistema de cotas
    O sistema de cotas é usado para determinar quanto espaço em disco é alocado para armazenamento. O sistema de cota gerencia cada partição como um bucket separado para determinar quanto espaço é permitido e quando ele é limpo.
    O método navigator.storage.estimate() agora fornece informações específicas para a partição de armazenamento. As APIs exclusivas do Chrome, como window.webkitStorageInfo e navigator.webkitTemporaryStorage, foram descontinuadas.
    O IndexedDB e o armazenamento em cache usam o sistema de cotas particionadas.
  • API Web Storage
    A API Web Storage oferece mecanismos para que os navegadores armazenem pares de chave-valor. Existem dois mecanismos: armazenamento local e armazenamento por sessão. Elas não são gerenciadas por cota, mas ainda são particionadas.
  • Sistema de arquivos particulares de origem
    A API File System Access permite que um site leia ou salve mudanças diretamente em arquivos e pastas no dispositivo depois que o usuário concede acesso. O Origin Private File System permite que uma origem armazene conteúdo privado diretamente no disco. Esse conteúdo continua acessível ao usuário, mas agora está particionado.
  • API Storage Bucket
    A API Storage Bucket está sendo desenvolvida para o Storage Standard, que consolida várias APIs de armazenamento, como IndexedDB e localStorage, usando um novo conceito chamado buckets. Os dados armazenados nos buckets e os metadados associados a eles são particionados.
  • Cabeçalho Clear-Site-Data
    Incluir o cabeçalho Clear-Site-Data na resposta permite que um servidor solicite a limpeza dos dados armazenados no navegador do usuário. O cache, os cookies e o armazenamento DOM podem ser limpos. Usar o cabeçalho limpa apenas o armazenamento em uma partição.
  • Armazenamento de URL de blob
    Um URL de blob fornece acesso a um blob, um objeto que contém dados brutos. Sem o particionamento de armazenamento, um URL de blob gerado em um iframe de terceiros em um site pode ser usado em um iframe de mesma origem incorporado em outro site. Por exemplo, se iframes example.com forem incorporados em a.com e b.com, um URL de blob gerado no iframe incorporado em a.com poderá ser transmitido e usado pelo iframe incorporado em b.com sem restrições. A partir do Chrome 137 (lançado em 27 de maio de 2025), os URLs de blob serão particionados para todos os usos, exceto navegações de nível superior. Os casos que agora serão bloqueados incluem o uso de URLs de blob entre partições com fetch() ou como o valor do atributo src para vários elementos HTML. Navegações de nível superior, como chamar window.open() ou clicar em um link com target='_blank', para URLs blob não serão bloqueadas se forem entre partições, mas noopener será aplicado se o site do URL blob for de um domínio diferente do site de nível superior da página que iniciou a navegação. Com o noopener aplicado, o documento que inicia a navegação não vai receber um identificador de janela para o documento URL do blob que ele abriu. No exemplo anterior, o particionamento impede que o iframe em b.com busque o conteúdo do URL do blob, mas ainda é possível window.open().

APIs de comunicação

Além das APIs de armazenamento, as APIs de comunicação que permitem que um contexto se comunique entre limites de origem também são particionadas. As mudanças afetam principalmente APIs que permitem a descoberta de outros contextos usando transmissão ou encontro de mesma origem.

Devido ao particionamento, as seguintes APIs de comunicação impedem que iframes de terceiros troquem dados com contextos de mesma origem:

  • Canal de transmissão
    A API Broadcast Channel permite a comunicação entre contextos de navegação (janelas, guias ou iframes) e workers da mesma origem.
    Não há proposta de mudança no comportamento do iframe postMessage() entre sites, já que a relação entre esses contextos já está claramente definida.
  • SharedWorker
    A API SharedWorker fornece um worker que pode ser acessado em contextos de navegação da mesma origem.
  • Bloqueios da Web
    A API Web Locks permite que o código em execução em uma guia ou worker da mesma origem adquira um bloqueio para um recurso compartilhado enquanto algum trabalho é realizado.

API Service Worker

A API Service Worker permite que os sites realizem tarefas em segundo plano. Os sites registram service workers que criam novos contextos de worker para responder a eventos. Tradicionalmente, esses workers podiam se comunicar com qualquer contexto de mesma origem. No entanto, como os service workers podem alterar o tempo das solicitações de navegação, eles representam um risco de vazamentos de informações entre sites, como detecção de histórico.

Por isso, os service workers registrados em um contexto de terceiros agora são particionados.

APIs de extensão

As extensões são programas que permitem que os usuários personalizem a experiência de navegação.

As páginas de extensão (páginas com um esquema chrome-extension://) podem ser incorporadas em sites na Web. Nesse cenário, as páginas de extensão continuam tendo acesso à partição de nível superior. As extensões também podem incorporar outros sites. Quando isso acontece, esses sites incorporados acessam a partição de nível superior, desde que a extensão tenha permissões de host para eles.

Para mais informações, consulte a documentação da extensão.

Demonstração: teste de particionamento de armazenamento

Site de demonstração: https://storage-partitioning-demo-site-a.glitch.me/

Site de demonstração mostrando marcas de seleção verdes à esquerda e cruzes vermelhas à direita.
Captura de tela da demonstração, mostrando a saída de um navegador com particionamento de armazenamento à esquerda e sem particionamento de armazenamento à direita.

A demonstração usa dois sites: A e B.

  • Quando você visita o site A no contexto de nível superior, ele define dados usando vários métodos de armazenamento.
  • O site B incorpora uma página do site A, e essa incorporação tenta ler as opções de armazenamento definidas anteriormente.
  • Quando o site A é incorporado ao site B, ele não tem acesso a esses dados quando o armazenamento é particionado, e as leituras falham.
  • A demonstração usa o sucesso ou a falha de cada leitura para mostrar se os dados estão particionados.

Por enquanto, é possível desativar o particionamento de armazenamento no Chrome usando a opção de linha de comando --disable-features=ThirdPartyStoragePartitioning. Observação: essa opção de linha de comando se destina a fins de desenvolvimento e teste e pode ser removida ou alterada em versões futuras do Chrome.

Você também pode testar outros navegadores da mesma forma para conferir o status de particionamento deles.

Solicitar mais tempo de migração

Para sites que precisam de mais tempo para migrar as dependências, o teste de suspensão de uso DisableThirdPartyStoragePartitioning3 foi estendido. Esse teste oferece um mecanismo temporário para que os sites de nível superior ativem o armazenamento não particionado, os workers de serviço e as APIs de comunicação para contextos de terceiros incorporados nas páginas.

Acesse Renovação do teste de descontinuação do particionamento de armazenamento para saber mais.

Engajamento e como compartilhar feedback