O Chrome vai desativar a modificação de document.domain para relaxar a política de mesma origem

Caso seu site dependa da configuração de document.domain, você precisa realizar uma ação.

Eiji Kitamura

Atualizações

  • 30 de maio de 2023: anunciamos que a descontinuação do setter document.domain vai entrar em vigor no Chrome 115.
  • 7 de abril de 2023: identificamos um problema antes de enviar essa mudança no Chrome 112. O setter document.domain a ser removido por padrão está suspenso no momento, e o novo marco de envio ainda não foi determinado. Confira esta postagem do blog ou inscreva-se em blink-dev e esta vertente.
  • 20 de janeiro de 2023: cronograma atualizado: o setter document.domain será removido por padrão a partir do Chrome 112. Além disso, uma menção sobre a política corporativa para controlar o comportamento de document.domain foi adicionada.
  • 25 de julho de 2022: cronograma atualizado: o setter document.domain será removido por padrão a partir do Chrome 109.
  • 4 de fevereiro de 2022: atualização com a nova linha do tempo. Vamos mostrar um aviso no painel "Issues" a partir do Chrome 100, removendo o setter document.domain por padrão a partir do Chrome 106.
.

document.domain foi criado para receber ou definir o nome do host da origem.

No Chrome, os sites não poderão definir document.domain. Você vai precisar usar abordagens alternativas, como postMessage() ou a API Channel Messaging, para se comunicar entre origens. O Chrome 112 é o objetivo para lançar essa mudança o mais rápido possível, mas isso depende da resposta à Intent to Ship.

Se o site depender do relaxamento de política de mesma origem por document.domain para funcionar corretamente, ele vai precisar enviar um cabeçalho Origin-Agent-Cluster: ?0, assim como todos os outros documentos que exigem esse comportamento. Observe que document.domain não tem efeito se apenas um documento o definir.

Por que tornar document.domain imutável?

Muitos sites definem document.domain para permitir a comunicação entre páginas no mesmo site, mas de origem cruzada.

Confira como ele é usado:

Digamos que uma página em https://parent.example.com incorpore uma página de iframe de https://video.example.com. Essas páginas têm o mesmo eTLD+1 (example.com) com subdomínios diferentes. Quando o document.domain das duas páginas está definido como 'example.com', o navegador trata as duas origens como se fossem da mesma origem.

Defina document.domain para https://parent.example.com:

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Defina document.domain para https://video.example.com:

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Agora é possível criar uma manipulação de DOM entre origens em https://parent.example.com contra https://video.example.com.

Os sites definem document.domain para facilitar a comunicação de documentos do mesmo site. Como essa mudança relaxa a política de mesma origem, a página mãe pode acessar o documento do iframe e percorrer a árvore DOM, e vice-versa.

Essa é uma técnica conveniente, mas que apresenta um risco de segurança.

Problemas de segurança com document.domain

As preocupações com a segurança em relação ao document.domain levaram a uma mudança na especificação que alerta os usuários para evitar o uso. A discussão atual com outros fornecedores de navegadores está seguindo na mesma direção.

Por exemplo, quando duas páginas definem document.domain, elas podem fingir que estão na mesma origem. Isso é particularmente importante quando essas páginas usam um serviço de hospedagem compartilhado com subdomínios diferentes. A configuração document.domain permite o acesso a todos os outros sites hospedados pelo mesmo serviço, o que facilita o acesso dos atacantes aos seus sites. Isso é possível porque document.domain ignora a parte do número da porta do domínio.

Para saber mais sobre as implicações de segurança da configuração document.domain, leia a página"Document.domain" no MDN.

O Chrome planeja tornar o document.domain imutável no Chrome 112.

Como saber se meu site foi afetado?

Se o site for afetado por essa mudança, o Chrome vai avisar no painel de problemas do DevTools. Observe a bandeira amarela no canto superior direito.

Quando document.domain é modificado, um aviso é exibido no painel "Issues".
Quando document.domain é modificado, um aviso é exibido no painel "Problemas".

Se você tiver um endpoint de relatórios configurado, também vai receber relatórios de descontinuação. Saiba como usar a API Reporting com serviços de coleta de relatórios ou criando sua própria solução interna.

Você pode passar seu site pela auditoria de API descontinuada do LightHouse (link em inglês) para encontrar todas as APIs programadas para ser removidas do Chrome.

Comunicação alternativa entre origens

No momento, você tem três opções para substituir document.domain no seu site.

Use a API postMessage() ou a API Channel Messaging

Na maioria dos casos de uso, postMessage() ou a API Channel Messaging podem substituir document.domain.

No exemplo a seguir:

  1. https://parent.example.com solicita https://video.example.com em um iframe para manipular o DOM enviando uma mensagem por postMessage().
  2. https://video.example.com manipula o DOM assim que recebe a mensagem e notifica a conclusão ao pai.
  3. https://parent.example.com confirma o sucesso.

Em https://parent.example.com:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

Em https://video.example.com:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

Teste e veja como funciona. Se você tiver requisitos específicos que não funcionem com postMessage() ou a API Channel Messaging, entre em contato pelo Twitter (@ChromiumDev) ou faça uma pergunta no Stack Overflow com uma tag document.domain.

Como último recurso, envie o cabeçalho Origin-Agent-Cluster: ?0.

Se você tiver motivos fortes para continuar definindo document.domain, envie o cabeçalho de resposta Origin-Agent-Cluster: ?0 com o documento de destino.

Origin-Agent-Cluster: ?0

O cabeçalho Origin-Agent-Cluster instrui o navegador se o documento precisa ser processado pelo cluster de agente com origin-key ou não. Para saber mais sobre Origin-Agent-Cluster, leia Como solicitar o isolamento de desempenho com o cabeçalho Origin-Agent-Cluster.

Quando você envia esse cabeçalho, o documento pode continuar definindo document.domain mesmo depois que ele se torna imutável por padrão.

Configurar OriginAgentClusterDefaultEnabled para a política corporativa

Como alternativa, o administrador pode configurar a política OriginAgentClusterDefaultEnabled para false para tornar o document.domain configurável por padrão nas instâncias do Chrome em toda a organização. Saiba mais em Gerenciamento e lista de políticas do Chrome Enterprise | Documentação.

Compatibilidade com navegadores

Recursos

Agradecimentos

Foto de Braydon Anderson no Unsplash