Chrome disattiverà la modifica del file document.domain per allentare il criterio della stessa origine

Se il tuo sito web si basa sull'impostazione document.domain, è necessaria la tua azione.

Aggiornamenti

  • 30 maggio 2023: abbiamo annunciato che il ritiro del settatore document.domain entrerà in vigore in Chrome 115.
  • 7 aprile 2023: abbiamo rilevato un problema prima di implementare questa modifica in Chrome 112. Il setter document.domain da rimuovere per impostazione predefinita è attualmente sospeso e il nuovo traguardo di rilascio non è ancora stato stabilito. Torna a visitare questo post del blog o iscriviti al canale blink-dev e a questo thread.
  • 20 gennaio 2023: tempistiche aggiornate: il set document.domain verrà ritirato per impostazione predefinita a partire da Chrome 112. Inoltre, è stata aggiunta una menzione relativa alle norme aziendali per controllare il comportamento di document.domain.
  • 25 luglio 2022: tempistiche aggiornate: il set document.domain verrà rimosso per impostazione predefinita a partire da Chrome 109.
  • 4 febbraio 2022: aggiornamento con le nuove tempistiche. A partire da Chrome 100, mostreremo un avviso nel riquadro Problemi a partire da Chrome 100, rimuovendo il setter document.domain per impostazione predefinita a partire da Chrome 106.

document.domain è stato progettato per recuperare o impostare il nome host dell'origine.

Su Chrome, i siti web non potranno impostare document.domain. Per comunicare tra origini diverse, dovrai utilizzare approcci alternativi, come postMessage() o l'API Channel Messaging. Abbiamo scelto come target Chrome 112 per implementare questa modifica al più presto, ma ciò dipende dalla risposta all'Intent to Ship (Intenzione di implementare).

Se il tuo sito web si basa sull'attenuazione delle norme relative all'origine tramite document.domain per funzionare correttamente, il sito dovrà inviare un Origin-Agent-Cluster: ?0 header, così come tutti gli altri documenti che richiedono questo comportamento (tieni presente che document.domain non ha alcun effetto se viene impostato solo in un documento).

Perché rendere document.domain immutabile?

Molti siti web impostano document.domain per consentire la comunicazione tra pagine stesso sito, ma multiorigine.

Ecco come viene utilizzato:

Supponiamo che una pagina su https://parent.example.com incorpori una pagina iframe di https://video.example.com. Queste pagine hanno lo stesso eTLD+1 (example.com) con sottodomini diversi. Quando document.domain di entrambe le pagine è impostato su 'example.com', il browser tratta le due origini come se fossero della stessa origine.

Imposta document.domain per 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);

Imposta document.domain per 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);

Ora puoi creare una manipolazione DOM cross-origin su https://parent.example.com contro https://video.example.com.

I siti web impostano document.domain per consentire ai documenti dello stesso sito di comunicare più facilmente. Poiché questa modifica rilasce il criterio della stessa origine, la pagina principale è in grado di accedere al documento dell'iframe e di attraversare la struttura DOM e viceversa.

Si tratta di una tecnica pratica, ma presenta un rischio per la sicurezza.

Problemi di sicurezza relativi a document.domain

I problemi di sicurezza relativi a document.domain hanno portato a una modifica della specifica che avvisa gli utenti di evitarne l'utilizzo. Anche l'attuale discussione con altri fornitori di browser si evolve nella stessa direzione.

Ad esempio, quando due pagine impostano document.domain, possono fingere di avere la stessa origine. Questo è particolarmente importante quando queste pagine utilizzano un servizio di hosting condiviso con sottodomini diversi. L'impostazione document.domain consente di accedere a tutti gli altri siti ospitati dallo stesso servizio, il che semplifica l'accesso degli utenti malintenzionati ai tuoi siti. Questo è possibile perché document.domain ignora la parte del numero di porta del dominio.

Per scoprire di più sulle implicazioni relative alla sicurezza dell'impostazione document.domain, consulta la pagina "Document.domain" su MDN.

Chrome prevede di rendere document.domain immutabile in Chrome 112.

Come faccio a sapere se il mio sito è interessato?

Se il tuo sito web è interessato da questa modifica, Chrome lo segnalerà nel riquadro dei problemi di DevTools. Nota l'indicatore giallo nell'angolo in alto a destra.

Quando document.domain viene modificato, nel riquadro Problemi viene visualizzato un avviso.
Quando document.domain viene modificato, nel riquadro Problemi viene visualizzato un avviso.

Se hai configurato un endpoint di generazione di report, ti verranno inviati anche i report sul ritiro. Scopri di più su come utilizzare l'API di reporting con i servizi di raccolta dei report esistenti o creando una tua soluzione interna.

Puoi sottoporre il tuo sito al controllo delle API ritirate di LightHouse per trovare tutte le API per le quali è stata pianificata la rimozione da Chrome.

Comunicazione cross-origin alternativa

Al momento, hai tre opzioni per sostituire document.domain per il tuo sito web.

Utilizzare postMessage() o l'API Channel Messaging

Nella maggior parte dei casi d'uso, postMessage() cross-origin o l'API Channel Messaging possono sostituire document.domain.

Nel seguente esempio:

  1. https://parent.example.com richiede https://video.example.com all'interno di un frame per manipolare il DOM inviando un messaggio tramite postMessage().
  2. https://video.example.com manipola il DOM non appena riceve il messaggio e comunica l'esito positivo al componente principale.
  3. https://parent.example.com riconosce il successo.

Il giorno 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
  }
});

Il giorno 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);
});

Prova e scopri come funziona. Se hai requisiti specifici che non funzionano con postMessage() o l'API Channel Messaging, comunicacelo su Twitter tramite @ChromiumDev o chiedi su Stack Overflow con un tag document.domain.

Come ultima risorsa, invia l'intestazione Origin-Agent-Cluster: ?0

Se hai valide ragioni per continuare a impostare document.domain, puoi inviare l'intestazione di risposta Origin-Agent-Cluster: ?0 insieme al documento di destinazione.

Origin-Agent-Cluster: ?0

L'intestazione Origin-Agent-Cluster indica al browser se il documento deve essere gestito o meno dal cluster di agenti con chiave di origine. Per scoprire di più su Origin-Agent-Cluster, leggi l'articolo Richiedere l'isolamento del rendimento con l'intestazione Origin-Agent-Cluster.

Quando invii questa intestazione, il documento può continuare a impostare document.domain anche dopo che diventa immutabile per impostazione predefinita.

Configurare OriginAgentClusterDefaultEnabled per i criteri aziendali

Se vuoi, l'amministratore può configurare il criterio OriginAgentClusterDefaultEnabled su false per rendere document.domain impostabile per impostazione predefinita nelle istanze di Chrome della tua organizzazione. Per saperne di più, leggi l'articolo Elenco e gestione dei criteri di Chrome Enterprise | Documentazione.

Compatibilità del browser

Risorse

Ringraziamenti

Foto di Braydon Anderson su Unsplash