Cross-Origin Opener Policy Memisahkan Relasi Window pada Browsing Context Boundary

Browser dapat mencegah cross-origin popup membaca sebagian besar properti opener-nya sambil tetap mempertahankan hubungan hidup antara kedua window. Same-origin policy membatasi akses langsung ke foreign document, tetapi cross-origin WindowProxy dapat tetap dapat dijangkau, mengekspos interface terbatas, ikut dalam navigation relationship, dan membawa observable state seperti apakah window yang direferensikan sudah ditutup.

Perbedaan ini penting bagi aplikasi yang menganggap origin separation sama dengan window separation. Halaman hostile dapat membuka site sensitif, atau site sensitif dapat membuka external service, sementara kedua document tetap berhubungan melalui browser-level context machinery. Cross-Origin-Opener-Policy (COOP) mengubah hubungan ini dengan mengontrol penempatan ke browsing context group.

COOP bukan content filter dan tidak memutuskan network response mana yang boleh dimuat. Efek keamanannya bersifat struktural: top-level document tertentu ditempatkan melintasi browsing context group boundary sehingga opener reference diputus ketika policy tidak mengizinkan hubungan tersebut.

Same-origin restriction tidak menghapus window relationship

Same-origin policy mencegah script memeriksa DOM dan JavaScript state milik cross-origin window secara bebas. Namun policy tersebut tidak membuat window lain menjadi tidak ada.

Ketika window.open() berhasil, caller biasanya menerima WindowProxy. Cross-origin access terhadap proxy itu sangat dibatasi, tetapi subset operation dan property tertentu tetap tersedia. Opened document juga dapat memiliki reference window.opener kecuali mekanisme lain menonaktifkannya.

Ini menciptakan perbedaan keamanan antara object access dan keberadaan relationship. Sebuah page tidak memerlukan arbitrary DOM access untuk setiap primitive serangan cross-origin. Browser state yang terlihat melalui window relationship dapat berkontribusi pada cross-site information leak, navigation attack, atau application coupling yang tidak dimaksudkan salah satu origin.

rel=noopener menangani bagian penting masalah ini pada link dengan menekan opener relationship untuk outgoing navigation. Feature noopener juga dapat diberikan ke window.open(). COOP bekerja di layer berbeda: ia adalah response policy pada document yang dimuat dan ikut dalam keputusan browser tentang browsing context group membership.

Ini membuat COOP berguna ketika protected document sendiri perlu mendeklarasikan isolation boundary, bukan hanya bergantung pada setiap external page yang mungkin membukanya.

Browsing context group membawa relationship lintas document

Browsing context adalah environment tempat document ditampilkan, biasanya tab, window, atau frame. Browsing context diorganisasikan ke browsing context group. Grouping ini penting karena context dalam satu group dapat mempertahankan reference dan relationship yang digunakan algoritma browser lintas navigation dan auxiliary window.

COOP menempelkan opener policy pada top-level document. Saat navigation dan popup operation tertentu, browser membandingkan policy serta origin untuk menentukan apakah document tetap berada dalam compatible group atau membutuhkan group baru.

Strict policy yang umum adalah:

Cross-Origin-Opener-Policy: same-origin

Dengan same-origin, document hanya mempertahankan compatible opener relationship dengan same-origin document yang membawa policy yang cocok. Cross-origin opener atau opened document ditempatkan melintasi group boundary sesuai aturan policy. Dari script, WindowProxy yang terkait relationship terputus dapat terlihat closed, dan opened document tidak mempertahankan ordinary opener connection.

Hasilnya lebih kuat daripada sekadar menolak pembacaan property pada cross-origin object. Browser mengubah topology yang membuat object relationship tersebut tersedia.

Policy matching bersifat bilateral

Perilaku COOP tidak dapat dimodelkan sebagai satu Boolean flag pada satu page. Hasilnya bergantung pada opener policy document yang terlibat, origin keduanya, dan operation yang menghubungkan mereka.

Default value unsafe-none mempertahankan model legacy kecuali policy document lain memaksa separation. same-origin meminta strict grouping dengan compatible same-origin document. same-origin-allow-popups mempertahankan deliberate exception untuk popup yang memakai unsafe-none, mendukung integrasi yang membutuhkan retained handle ke external popup. Platform juga mendefinisikan noopener-allow-popups, yang memaksakan separation pada protected document sambil mempertahankan popup behavior tertentu.

Bilateral matching ini memiliki konsekuensi operasional: mengubah COOP pada satu endpoint dapat mengubah perilaku JavaScript di aplikasi lain yang membukanya atau dibukanya. Payment flow, identity provider, support console, atau document preview dapat bergantung pada live WindowProxy walaupun kedua sisi tidak dapat membaca DOM masing-masing secara langsung.

Kegagalan dapat terlihat seperti application breakage biasa, bukan network atau authentication error. Popup tetap terbuka, remote service tetap menyelesaikan tugasnya, HTTP traffic tetap valid, tetapi opener dapat kehilangan reference semantics yang diharapkan completion logic.

Popup identity flow memperlihatkan compatibility trade-off

Pertimbangkan aplikasi yang membuka identity provider dalam popup lalu menunggu popup selesai. Sebagian desain memakai postMessage() antara popup dan opener; desain lain melakukan polling pada property yang diizinkan atau mengandalkan retained window handle sebagai bagian lifecycle management.

Menerapkan Cross-Origin-Opener-Policy: same-origin pada aplikasi dapat memutus cross-origin popup relationship. Jika integrasi membutuhkan hubungan tersebut, strict isolation bertentangan dengan integration architecture.

same-origin-allow-popups tersedia untuk kasus ketika protected document membutuhkan separation lebih kuat dari arbitrary opener tetapi harus mempertahankan reference ke popup yang memakai unsafe-none. Ini adalah compatibility concession, bukan isolation yang setara. Relationship yang diizinkan sengaja dipertahankan, sehingga security analysis harus memasukkan external popup dan data yang dipertukarkan melalui channel tersebut.

Karena itu policy value harus mencerminkan window graph aplikasi yang sebenarnya. Men-deploy token paling ketat tanpa mempertimbangkan popup dependency dapat merusak flow sah; memilih token permissive hanya untuk mempertahankan legacy behavior dapat meninggalkan relationship yang sebenarnya tidak dibutuhkan aplikasi.

COOP mempersempit kelas cross-origin observation

Cross-origin window reference secara historis menyediakan bahan bagi teknik cross-site leak. Walaupun hostile origin tidak dapat membaca body response sensitif, ia mungkin dapat mengamati side effect atau browser state yang berkorelasi dengan response tersebut.

Memisahkan browsing context group menghapus sekumpulan direct opener relationship yang dapat digunakan teknik seperti ini. Ia juga mengurangi unintended coupling antara protected top-level document dan cross-origin window yang tidak terkait.

Cakupannya harus dinyatakan presisi. COOP bukan pertahanan universal terhadap XS-Leak. Ia tidak membuat semua cross-origin state tidak dapat diamati, tidak menghapus network timing, tidak menggantikan cache partitioning, tidak membatasi setiap embedding relationship, dan tidak memperbaiki application message yang membocorkan data sensitif. Site yang mengirim secret ke untrusted origin melalui postMessage() memiliki explicit data-flow defect yang tidak dapat diperbaiki header.

COOP juga tidak mengubah same-origin code menjadi principal yang saling tidak percaya. Script yang berbagi origin tetap memiliki authority yang diberikan origin model kecuali ada platform boundary lain. Aplikasi yang menempatkan service berisiko tinggi dan rendah pada origin yang sama tidak dapat memakai COOP saja sebagai pengganti origin separation.

Process isolation dapat menjadi konsekuensi, bukan kontrak policy

Dokumentasi browser sering membahas COOP bersama process isolation, tetapi kontrak keamanan sebaiknya tidak direduksi menjadi janji bahwa setiap protected site mendapat dedicated operating-system process.

Mekanisme web-platform dinyatakan dalam bentuk browsing context group dan opener policy. Browser dapat memakai process boundary sebagai bagian implementasi dan site-isolation strategy-nya, tetapi process allocation adalah implementation concern dengan constraint spesifik browser.

Memperlakukan COOP sebagai process-placement API menciptakan security assumption yang rapuh. Efek application-facing yang dapat diandalkan adalah perilaku context-group dan opener relationship yang didefinisikan platform. Security architecture sebaiknya bergantung pada semantik tersebut, bukan inferred process layout.

Perbedaan ini juga penting untuk klaim side-channel. Process separation dapat mengurangi exposure terhadap sebagian kelas speculative-execution attack, tetapi COOP sendiri bukan cross-origin isolation mechanism lengkap yang digunakan untuk akses ke capability sensitif seperti shared memory.

Cross-origin isolation menggabungkan opener dan embedding control

Document yang ingin mencapai cross-origin isolated state pada web platform umumnya membutuhkan konfigurasi COOP dan Cross-Origin-Embedder-Policy (COEP) yang kompatibel, sesuai aturan platform dan permissions policy yang berlaku.

Kedua policy mengatur boundary berbeda. COOP menangani top-level opener relationship dan browsing context grouping. COEP membatasi cross-origin resource yang dapat dimuat ke environment document kecuali resource tersebut secara eksplisit mengizinkan hubungan melalui mekanisme seperti CORS atau Cross-Origin-Resource-Policy.

Pembagian ini mencegah configuration error umum: mengatur COOP lalu menganggap semua cross-origin subresource kini terisolasi, atau mengatur COEP lalu menganggap hostile top-level opener sudah terputus. Header tersebut saling melengkapi karena mengatur edge berbeda dalam relationship graph browser.

Aplikasi yang membutuhkan SharedArrayBuffer dan capability lain yang bergantung pada cross-origin isolation harus memenuhi seluruh requirement state. Deployment COOP yang berhasil saja tidak membentuk state tersebut.

Reporting dapat mengekspos breakage sebelum enforcement

COOP memiliki report-only form yang dapat membantu menemukan relationship yang akan terganggu jika enforcement diaktifkan:

Cross-Origin-Opener-Policy-Report-Only: same-origin

Report-only operation tidak menciptakan isolation boundary yang sama dengan enforcement. Nilainya bersifat diagnostik: browser dapat melaporkan policy interaction yang seharusnya menyebabkan separation, tergantung reporting configuration dan browser support yang digunakan.

Perbedaan ini penting pada staged deployment. Telemetry dapat menunjukkan popup integration, auxiliary window, dan unexpected opener relationship, tetapi report stream yang bersih bukan security guarantee. Coverage bergantung pada client, reporting endpoint, sampling atau delivery behavior, dan traffic yang terwakili selama observasi.

Enforcement tetap perlu diuji pada authentication, payment, federated tool, dan feature apa pun yang membuka atau dibuka top-level document lain.

Penempatan header adalah bagian dari boundary

COOP adalah response header yang diinterpretasikan untuk document. Mengaturnya dalam application code hanya efektif jika final response yang mencapai browser membawa value yang dimaksud.

Reverse proxy, CDN, route-specific handler, error page, dan authentication middleware dapat menghasilkan header berbeda untuk response berbeda. Protected route yang melakukan redirect melalui endpoint tanpa expected policy dapat ikut dalam browser behavior yang berbeda dari final application page.

Karena itu operational verification harus dilakukan pada delivered-response layer. Pertanyaan yang relevan bukan apakah framework configuration memiliki setting COOP, melainkan apakah setiap security-sensitive top-level response membawa policy sesuai perannya dan apakah related popup endpoint tetap kompatibel.

Policy consistency juga penting di antara same-origin document yang diharapkan mempertahankan relationship. Karena matching rule mempertimbangkan policy dan origin, header yang tidak konsisten dapat memisahkan context yang sebelumnya diasumsikan tetap terhubung oleh application code.

Security boundary-nya adalah browser relationship boundary

COOP paling akurat diperlakukan sebagai kontrol terhadap topology relationship browser. Ia tidak mengautentikasi remote origin, mengotorisasi request, melakukan sanitization script, atau membatasi server-side data access. Ia menentukan kapan top-level document boleh tetap dikelompokkan bersama opener atau opened document sesuai policy rule platform.

Boundary ini bernilai karena origin-based access check dan window connectivity adalah konsep berbeda. Cross-origin window dapat tidak dapat diakses untuk ordinary DOM read tetapi tetap ikut dalam relationship yang mengekspos browser state berguna atau mendukung application communication.

Deployment memperoleh properti keamanan yang dimaksud ketika policy yang dipilih cocok dengan popup graph aplikasi yang nyata, strict page menerima header pada setiap response relevan, dan surviving cross-origin communication diperlakukan sebagai explicit trust decision. Header-nya kecil; boundary yang diubahnya mencakup model browser tentang top-level document mana yang tetap terhubung.