Origin-Agent-Cluster Memisahkan Heap JavaScript Berbasis Origin

Origin web yang berada dalam satu site tetap dapat menjadi principal keamanan yang berbeda. app.example.com dan admin.example.com, misalnya, memiliki origin berbeda meskipun keduanya berada di bawah registrable domain yang sama. Arsitektur proses browser secara historis dapat menempatkan origin terkait dalam agent cluster yang sama pada kondisi tertentu, sehingga lingkungan eksekusi JavaScript mereka lebih berdekatan daripada yang tersirat dari model berbasis origin saja.

Header response Origin-Agent-Cluster memberi dokumen cara untuk meminta clustering berbasis origin:

Origin-Agent-Cluster: ?1

Pada browser yang mendukungnya, opt-in tersebut meminta user agent menempatkan origin dalam agent cluster yang dikunci berdasarkan origin, bukan site. Dampak praktisnya adalah pemisahan eksekusi yang lebih tegas antar-origin dalam site yang sama: dokumen pada cluster berbeda tidak berbagi heap JavaScript dan tidak dapat mengakses object satu sama lain secara sinkron.

Properti ini berguna, tetapi cakupannya sempit. Header tersebut bukan access-control list, tidak menggantikan same-origin policy, dan tidak menjanjikan proses sistem operasi khusus. Yang berubah adalah batas isolasi internal browser.

Agent cluster menentukan jangkauan JavaScript sinkron

Agent cluster mengelompokkan browsing context yang agent JavaScript-nya berpotensi berinteraksi secara sinkron. Object dalam satu cluster dapat mengikuti mekanisme yang bergantung pada lingkungan eksekusi bersama. Object pada cluster berbeda tidak dapat langsung berbagi object JavaScript atau semantik memori sinkron.

Origin-keying menjadikan origin sebagai key yang relevan untuk pengelompokan tersebut. Dokumen dari https://app.example.com dan dokumen dari https://admin.example.com menempati cluster berbasis origin yang berbeda ketika kebijakan berlaku, walaupun kedua origin tersebut berada dalam site yang sama.

Perbedaan ini paling relevan pada aplikasi yang sengaja memisahkan komponen melalui subdomain. Sebuah site dapat menempatkan administrasi akun, konten buatan pengguna, atau aplikasi lama pada origin berbeda untuk mengurangi coupling. Clustering berbasis origin dapat memperkuat arsitektur tersebut pada lapisan eksekusi browser.

Mekanisme ini tidak membuat logika aplikasi yang tidak aman menjadi aman. Receiver postMessage yang terlalu permisif, API yang terekspos, atau kelemahan otorisasi server tetap menjadi masalah terlepas dari penempatan agent cluster.

Header merupakan komitmen untuk satu origin

Browser tidak dapat dengan aman mencampur clustering berbasis origin dan berbasis site untuk dokumen dari origin yang sama pada saat bersamaan. Karena itu, pilihan efektif terkait dengan origin, bukan hanya satu response secara terpisah.

Deployment sebaiknya mengirim header secara konsisten untuk origin tersebut. Memasangnya hanya pada route sensitif sementara route lain tidak konsisten menghasilkan kebijakan yang sulit dianalisis dan mungkin tidak memberikan hasil yang dimaksud pada setiap navigasi.

Konfigurasi representatifnya sederhana:

Origin-Agent-Cluster: ?1

Nilai structured header ?1 berarti true. Header ditempatkan pada response dokumen untuk origin yang hendak melakukan opt-in.

Konsistensi juga penting antar-tier aplikasi. Jika CDN, reverse proxy, dan application server masing-masing dapat menghasilkan HTML, jalur response akhir perlu mempertahankan kebijakan yang sama. Header yang hanya muncul dari satu backend bukan kebijakan origin yang andal.

Origin-keying tidak menjamin proses terpisah

Pernyataan yang terlalu luas adalah bahwa Origin-Agent-Cluster: ?1 memberikan proses browser khusus untuk sebuah origin. Platform tidak memberikan jaminan tersebut.

Browser tetap memiliki kebebasan dalam alokasi proses. Batas resource, strategi implementasi, batasan platform, dan mekanisme isolasi lain dapat memengaruhi apakah dua agent cluster berada pada proses sistem operasi yang berbeda. Kontraknya menyangkut pemisahan agent cluster, bukan topologi proses yang tetap.

Perbedaan ini relevan bagi keamanan. Arsitektur tidak boleh memperlakukan header tersebut sebagai bukti bahwa dua origin tidak mungkin berbagi proses. Kontrol yang membutuhkan isolasi proses perlu bergantung pada mekanisme browser dengan jaminan terdokumentasi yang sesuai dengan kebutuhan tersebut, sambil tetap memperhitungkan batas implementasi browser.

Clustering berbasis origin lebih tepat diperlakukan sebagai defense in depth: mekanisme ini mengurangi coupling JavaScript sinkron antar-origin dan dapat mendukung isolasi browser yang lebih kuat, tetapi bukan deklarasi process sandbox.

document.domain bertentangan dengan isolasi berbasis origin

Aplikasi web lama terkadang menetapkan document.domain agar sibling subdomain dapat melonggarkan hubungan origin dan berkomunikasi secara sinkron. Pola tersebut melemahkan pemisahan yang hendak dibentuk oleh clustering berbasis origin.

Untuk dokumen dalam agent cluster berbasis origin, upaya mengubah document.domain tidak memberikan relaksasi cross-origin lama tersebut. Aplikasi yang masih bergantung pada mekanisme itu memerlukan migrasi sebelum header digunakan sebagai langkah isolasi.

Komunikasi cross-origin modern sebaiknya memakai channel eksplisit seperti postMessage, dengan pemeriksaan ketat terhadap origin pengirim yang diharapkan dan bentuk message. Messaging eksplisit membuat perpindahan trust terlihat dalam kode aplikasi alih-alih menggabungkan identitas origin melalui document.domain.

Migrasi ini dapat membuka dependency tersembunyi. Widget lama, tool administrasi yang di-embed, atau integrasi sibling-domain mungkin telah bergantung pada akses DOM sinkron selama bertahun-tahun. Pengujian perlu mencakup jalur tersebut sebelum rollout luas.

Messaging cross-origin tetap tersedia

Pemisahan agent cluster tidak melarang seluruh komunikasi antar-origin. Mekanisme browser asinkron yang dirancang untuk interaksi cross-origin tetap tersedia sesuai aturannya masing-masing.

window.postMessage() adalah contoh yang paling umum. Sebuah dokumen dapat mengirim message ke browsing context lain tanpa berbagi heap JavaScript. Receiver tetap perlu memvalidasi event.origin, memvalidasi struktur message, dan menolak operasi yang tidak diharapkan.

Pemisahan ini berguna secara arsitektural. Komponen dapat mempertahankan batas message yang eksplisit sambil menghindari akses object sinkron. Review keamanan kemudian memiliki permukaan protokol yang konkret: origin yang diterima, jenis message, validasi payload, dan keputusan otorisasi.

Header tidak melakukan pemeriksaan tersebut. Header mengubah pengelompokan eksekusi; kode aplikasi tetap memiliki kebijakan trust untuk messaging.

Header isolasi menangani masalah yang berbeda

Origin-Agent-Cluster berada berdampingan dengan beberapa kontrol isolasi browser, tetapi fungsi mereka tidak dapat saling menggantikan.

Cross-Origin-Opener-Policy mengontrol hubungan antar-browsing context top-level dan dapat memutus hubungan opener melewati batas kebijakan. Cross-Origin-Embedder-Policy mengontrol pemuatan resource cross-origin tertentu kecuali resource tersebut secara eksplisit mengizinkan pemuatan. Kombinasi kebijakan COOP dan COEP yang sesuai dapat membentuk cross-origin isolation yang dibutuhkan oleh sejumlah fitur browser berkemampuan tinggi.

Origin-Agent-Cluster memiliki sasaran berbeda. Header ini meminta agent clustering berbasis origin. Mengirimnya saja tidak membentuk cross-origin isolation, tidak memenuhi persyaratan resource COEP, dan tidak menetapkan framing policy.

Deployment sebaiknya memilih header berdasarkan batas yang diperlukan, bukan mengumpulkan security header sebagai paket generik. Setiap header memiliki biaya kompatibilitas dan semantik enforcement sendiri.

Rollout dimulai dari pemetaan dependency

Sebelum mengaktifkan clustering berbasis origin, inventarisasi origin dalam site yang saling bertukar data di browser. Beri perhatian khusus pada kode yang menyentuh sibling window atau frame secara sinkron, menulis document.domain, atau mengasumsikan akses object langsung antar-subdomain.

Kemudian buat kebijakan konsisten pada origin target dan uji jalur navigasi yang dapat dilayani oleh infrastruktur berbeda. Developer tools browser dan integration test dapat menampilkan interaksi lama yang rusak, tetapi pengujian pada level aplikasi tetap penting karena halaman dapat berhasil dirender sementara workflow cross-origin lama berhenti tanpa gejala yang jelas.

Batas messaging eksplisit perlu ditinjau pada saat yang sama. Memindahkan integrasi lama dari akses sinkron ke postMessage belum selesai sampai validasi sender dan receiver dibuat presisi.

Agent cluster berbasis origin menyediakan primitive isolasi yang terfokus. Mekanisme ini paling efektif ketika aplikasi memang memperlakukan origin sebagai batas trust yang bermakna dan memakai protokol eksplisit ketika data harus melintasi batas tersebut.