Particionamento de armazenamento

Para fortalecer 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 no 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 o Firefox e o Safari. A proposta de particionamento de armazenamento no GitHub está aberta para mais discussões.

O que é a partição de armazenamento?

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

Sem particionamento de armazenamento, um site pode mesclar 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.

Historicamente, o armazenamento era chaveado apenas pela origem. Isso significa que, se um iframe de example.com for incorporado a 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, a partição significa que os dados gravados por APIs de armazenamento, como o Local Storage e o IndexedDB em um iframe, não podem mais ser acessados por todos os contextos que compartilham a mesma origem. Agora, esses dados estã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 Storage sem particionamento.
Antes do particionamento de armazenamento, o example.com pode gravar dados quando incorporado no a.com e depois ler quando incorporado no b.com.

Depois

APIs Storage com particionamento.
Depois do particionamento de armazenamento, o example.com, quando incorporado no b.com, não pode acessar o armazenamento do example.com quando incorporado no 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 a partição considerar apenas o site de nível superior e a origem do frame atual, o iframe A2 poderá ser tratado erroneamente como "de primeira parte" porque compartilha um site com o nível superior (A1), apesar do iframe B entre os sites. Isso poderia expor o A2 a riscos de segurança, como clickjacking, se o A2 tivesse acesso ao armazenamento não particionado por padrão.

Para resolver esse problema, o Chrome adiciona um "bit ancestral" à chave de partição de armazenamento. Esse bit é definido se qualquer 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 dele seria particionado de A1.

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

Para sites que precisam de acesso não particionado em iframes encadeados, o Chrome está testando a extensão da API Storage Access para permitir esse caso de uso. Como a API Storage Access exige que o site enquadrado 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 do Storage

  • Sistema de cotas
    O sistema de cota é 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 da partição de armazenamento. APIs exclusivas do Chrome, como window.webkitStorageInfo e navigator.webkitTemporaryStorage, foram descontinuadas.
    O IndexedDB e o armazenamento em cache usam o sistema de cota particionada.
  • API Web Storage
    A API Web Storage oferece mecanismos pelos quais os navegadores podem armazenar pares de chave-valor. Há dois mecanismos: armazenamento local e armazenamento de sessão. Eles não são gerenciados por cota, mas ainda são particionados.
  • Sistema de arquivos particular do Origin
    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 sistema de arquivos particular da origem permite que uma origem armazene conteúdo particular diretamente no disco. Esse conteúdo ainda pode ser acessado pelo 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. O uso do cabeçalho apenas limpa o armazenamento em uma partição.
  • Armazenamento de URLs de blobs
    Um URL de blob fornece acesso a um blob, um objeto que armazena 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 a a.com e b.com, um URL de blob gerado no iframe incorporado a a.com poderá ser transmitido e, em seguida, usado pelo iframe incorporado a b.com sem restrições. A partir do Chrome 137 (lançado em 27 de maio de 2025), os URLs de blob são particionados para todos os usos, exceto navegações de nível superior. Os casos que serão bloqueados incluem quando URLs de blobs entre partições são usados com fetch() ou como o valor do atributo src para vários elementos HTML. As 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 inicia a navegação. A aplicação de noopener significa que o documento que inicia a navegação não poderá receber um identificador de janela para o documento de URL 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 pode 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 os limites de origem também são particionados. As mudanças afetam principalmente APIs que permitem a descoberta de outros contextos usando transmissão ou encontros de mesma origem.

Devido ao particionamento, as APIs de comunicação a seguir impedem que iframes de terceiros troquem dados com os 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 é proposta a alteração do 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 executado em uma guia ou worker da mesma origem adquira uma trava 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 vazamento de informações entre sites, como sniffing de histórico.

Por esse motivo, 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 aos usuários personalizar a experiência de navegação.

As páginas de extensão (páginas com um esquema chrome-extension://) podem ser incorporadas a sites na Web. Nesse cenário, as páginas da 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: como testar a partição 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 à direita.

A demonstração usa dois sites: site A e site 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 são particionados.

Por enquanto, é possível desativar o particionamento de armazenamento no Chrome usando a chave de linha de comando --disable-features=ThirdPartyStoragePartitioning. Observação: essa chave de linha de comando é destinada 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 descontinuação do DisableThirdPartyStoragePartitioning3 foi estendido. Esse teste oferece um mecanismo temporário para que sites de nível superior ativem o armazenamento não particionado, workers de serviço e 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 compartilhamento de feedback