Chrome akan menonaktifkan modifikasi document.domain untuk menyesuaikan kebijakan asal yang sama

Jika situs Anda bergantung pada setelan document.domain, tindakan Anda diperlukan.

Eiji Kitamura
Eiji Kitamura

Update

  • 30 Mei 2023: kami telah mengumumkan bahwa penghentian penyetel document.domain akan berlaku di Chrome 115.
  • 7 April 2023: Kami telah mengidentifikasi masalah sebelum mengirimkan perubahan ini di Chrome 112. Penyetel document.domain yang akan dihapus secara default saat ini ditangguhkan dan tahap pencapaian pengiriman baru belum ditentukan. Periksa kembali postingan blog ini atau berlangganan blink-dev dan rangkaian pesan ini.
  • 20 Januari 2023: Linimasa yang diperbarui—penyetel document.domain akan dihapus secara default mulai Chrome 112. Selain itu, penyebutan tentang kebijakan perusahaan untuk mengontrol perilaku document.domain ditambahkan.
  • 25 Juli 2022: Linimasa yang diperbarui—penyetel document.domain akan dihapus secara default mulai Chrome 109.
  • 4 Februari 2022: Diperbarui dengan linimasa baru - kami akan menampilkan peringatan di panel Masalah mulai dari Chrome 100, menghapus penyetel document.domain secara default mulai dari Chrome 106.

document.domain dirancang untuk mendapatkan atau menyetel nama host asal.

Di Chrome, situs tidak dapat menyetel document.domain. Anda harus menggunakan pendekatan alternatif, seperti postMessage() atau Channel Messaging API, untuk berkomunikasi lintas origin. Kami menargetkan Chrome 112 untuk mengirimkan perubahan ini paling awal, tetapi hal ini bergantung pada respons terhadap Intent to Ship.

Jika situs Anda mengandalkan pelonggaran kebijakan origin sama melalui document.domain agar berfungsi dengan benar, situs tersebut harus mengirim header Origin-Agent-Cluster: ?0, begitu pula semua dokumen lain yang memerlukan perilaku tersebut (perhatikan bahwa document.domain tidak akan berpengaruh jika hanya satu dokumen yang menetapkannya).

Mengapa membuat document.domain tidak dapat diubah?

Banyak situs menetapkan document.domain untuk memungkinkan komunikasi antara halaman situs yang sama tetapi lintas origin.

Berikut cara penggunaannya:

Misalnya, halaman di https://parent.example.com menyematkan halaman iframe dari https://video.example.com. Halaman ini memiliki eTLD+1 (example.com) yang sama dengan subdomain yang berbeda. Jika document.domain kedua halaman disetel ke 'example.com', browser akan memperlakukan kedua origin tersebut seolah-olah berasal yang sama.

Tetapkan document.domain untuk 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);

Tetapkan document.domain untuk 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);

Anda kini dapat membuat manipulasi DOM lintas origin pada https://parent.example.com terhadap https://video.example.com.

Situs menetapkan document.domain untuk memudahkan dokumen di situs yang sama berkomunikasi. Karena perubahan ini melonggarkan kebijakan origin yang sama, halaman induk dapat mengakses dokumen iframe dan melewati hierarki DOM, dan sebaliknya.

Ini adalah teknik yang praktis, tetapi dapat menimbulkan risiko keamanan.

Masalah keamanan pada document.domain

Masalah keamanan seputar document.domain telah menyebabkan perubahan pada spesifikasi yang memperingatkan pengguna untuk menghindari penggunaannya. Diskusi saat ini dengan vendor browser lainnya berjalan ke arah yang sama.

Misalnya, saat dua halaman menetapkan document.domain, halaman tersebut dapat berpura-pura seolah-olah memiliki asal yang sama. Hal ini sangat penting terutama saat halaman ini menggunakan layanan hosting bersama dengan subdomain yang berbeda. Menyetel document.domain akan membuka akses ke semua situs lain yang dihosting oleh layanan yang sama, yang memudahkan penyerang mengakses situs Anda. Hal ini memungkinkan karena document.domain mengabaikan bagian nomor port domain.

Untuk mempelajari lebih lanjut implikasi keamanan dari menetapkan document.domain, baca halaman"Document.domain" di MDN.

Chrome berencana membuat document.domain tidak dapat diubah di Chrome 112.

Bagaimana cara mengetahui apakah situs saya terpengaruh?

Jika situs Anda terpengaruh oleh perubahan ini, Chrome akan memberikan peringatan di panel DevTools Issues. Perhatikan bendera kuning di sudut kanan atas.

Saat document.domain diubah, peringatan akan ditampilkan di panel
Issues.
Jika document.domain diubah, peringatan akan ditampilkan di panel Masalah.

Jika telah menyiapkan endpoint pelaporan, Anda juga akan menerima laporan penghentian penggunaan. Pelajari lebih lanjut cara menggunakan Reporting API dengan layanan pengumpulan laporan yang ada atau dengan membuat solusi internal Anda sendiri.

Anda dapat menjalankan situs melalui audit API LightHouse yang tidak digunakan lagi untuk menemukan semua API yang dijadwalkan untuk dihapus dari Chrome.

Komunikasi lintas asal alternatif

Saat ini, Anda memiliki tiga opsi guna mengganti document.domain untuk situs Anda.

Gunakan postMessage() atau Channel Messaging API

Pada sebagian besar kasus penggunaan, postMessage() lintas origin atau Channel Messaging API dapat menggantikan document.domain.

Dalam contoh berikut:

  1. https://parent.example.com meminta https://video.example.com di dalam iframe untuk memanipulasi DOM dengan mengirim pesan melalui postMessage().
  2. https://video.example.com memanipulasi DOM segera setelah menerima pesan dan memberitahukan keberhasilan kembali ke induk.
  3. https://parent.example.com mengonfirmasi keberhasilannya.

Di 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
  }
});

Di 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);
});

Cobalah dan lihat cara kerjanya. Jika Anda memiliki persyaratan khusus yang tidak berfungsi dengan postMessage() atau Channel Messaging API, beri tahu kami di Twitter melalui @ChromiumDev atau tanyakan di Stack Overflow dengan tag document.domain.

Sebagai upaya terakhir, kirim header Origin-Agent-Cluster: ?0

Jika memiliki alasan kuat untuk terus menetapkan document.domain, Anda dapat mengirim header respons Origin-Agent-Cluster: ?0 beserta dokumen target.

Origin-Agent-Cluster: ?0

Header Origin-Agent-Cluster menginstruksikan browser apakah dokumen harus ditangani oleh cluster agen dengan kunci origin atau tidak. Untuk mempelajari Origin-Agent-Cluster lebih lanjut, baca Meminta isolasi performa dengan header Origin-Agent-Cluster.

Saat header ini dikirim, dokumen Anda dapat terus menetapkan document.domain meskipun tidak dapat diubah secara default.

Konfigurasi OriginAgentClusterDefaultEnabled untuk kebijakan perusahaan

Secara opsional, admin Anda dapat mengonfigurasi kebijakan OriginAgentClusterDefaultEnabled ke false agar document.domain dapat disetel secara default pada instance Chrome di seluruh organisasi Anda. Untuk mempelajari lebih lanjut, baca Daftar & Pengelolaan Kebijakan Chrome Enterprise | Dokumentasi.

Kompatibilitas browser

Referensi

Ucapan terima kasih

Foto oleh Braydon Anderson di Unsplash