Cross-Origin-Resource-Policy Membatasi Embedding No-CORS

Banyak elemen browser dapat meminta resource lintas origin tanpa memakai CORS. Image, script, media, dan subresource lain dapat melewati jalur fetch no-cors ketika halaman tidak memperoleh akses normal dari script ke body response. Pembatasan tersebut berguna, tetapi load cross-origin yang tidak diinginkan tetap dapat mengekspos resource pada embedding atau kondisi side-channel.

Header response Cross-Origin-Resource-Policy, yang umum disingkat CORP, memungkinkan pemilik resource menyatakan hubungan site yang diizinkan untuk load no-cors tersebut.

Cross-Origin-Resource-Policy: same-origin

Browser yang mendukung CORP melakukan pemeriksaan pada response. Ketika konteks request melanggar kebijakan yang dinyatakan, request jaringan mungkin sudah mencapai server; enforcement mencegah body response dikirim ke konteks peminta. Karena itu, CORP merupakan kontrol isolasi pada sisi response, bukan aturan firewall yang menghentikan packet sebelum mencapai endpoint.

Tiga nilai menyatakan batas resource

CORP menerima tiga nilai kebijakan:

same-origin adalah pilihan paling sempit. Nilai ini cocok untuk resource privat yang tidak memiliki kebutuhan embedding cross-origin yang sah.

same-site lebih luas. Nilai ini dapat cocok pada arsitektur yang memang mempercayai sibling origin, tetapi keputusan tersebut perlu diperiksa dengan cermat. Subdomain konten user dan subdomain administrasi dapat berada pada site yang sama walaupun memiliki tingkat trust yang sangat berbeda.

cross-origin adalah sinyal berbagi yang eksplisit. Nilai ini berguna untuk resource yang memang dikonsumsi origin lain dan juga berperan pada deployment yang memakai Cross-Origin-Embedder-Policy.

CORP menargetkan jalur request no-cors

CORP tidak menggantikan CORS. Kedua mekanisme bekerja pada jalur request berbeda dan menjawab kebijakan yang berbeda.

Resource yang di-fetch dalam mode CORS diatur oleh CORS. Resource yang dimuat melalui jalur no-cors yang dicakup dapat dibatasi oleh CORP. Sebagai contoh, elemen image tanpa opt-in CORS dapat menghasilkan request no-cors:

<img src="https://assets.example.net/private-chart.png" alt="">

Jika response menyatakan:

Cross-Origin-Resource-Policy: same-origin

dokumen pada origin lain tidak dapat berhasil mengonsumsi response tersebut melalui load no-cors yang dicakup.

Fakta bahwa request dapat mencapai server merupakan detail operasional penting. CORP tidak boleh diperlakukan sebagai perlindungan terhadap perubahan state yang terjadi hanya karena server menerima request. Endpoint tetap memerlukan pertahanan CSRF dan semantik HTTP yang aman jika relevan.

Kebijakan resource berbeda dari kebijakan framing dokumen

CORP kadang dikelompokkan dengan header yang mengontrol embedding dokumen, tetapi kontraknya berbeda.

Content-Security-Policy: frame-ancestors mengontrol ancestor yang boleh melakukan framing terhadap dokumen. X-Frame-Options menyediakan pembatasan framing yang lebih lama. CORP mengontrol apakah response resource dapat dikirim melalui request no-cors cross-origin atau cross-site yang dicakup.

Memakai CORP pada response HTML tidak menjadikannya pengganti kebijakan framing. Sebaliknya, aturan frame-ancestors yang ketat tidak menetapkan batas CORP untuk image, script, atau subresource lain yang disajikan aplikasi yang sama.

Kumpulan security header lebih mudah diaudit ketika setiap header dikaitkan dengan batas yang benar-benar ditegakkannya.

COEP dapat mewajibkan consent resource yang eksplisit

Cross-Origin-Embedder-Policy mengubah persyaratan embedding sebuah dokumen. Dengan Cross-Origin-Embedder-Policy: require-corp, resource cross-origin yang dimuat dalam mode no-cors memerlukan kebijakan CORP yang sesuai dan mengizinkan hubungan embedding tersebut, kecuali load memakai CORS dan berhasil menurut aturan CORS.

Hubungan tersebut membuat cross-origin tetap bermakna walaupun terdengar permisif:

Cross-Origin-Resource-Policy: cross-origin

Untuk server aset publik, header tersebut dapat menyatakan secara eksplisit bahwa resource memang ditujukan untuk konsumsi cross-origin. Dokumen yang menegakkan COEP kemudian dapat menerima consent tersebut untuk load resource no-cors yang relevan.

Ini tidak berarti setiap resource pada origin aset harus menerima header yang sama. Font publik, export akun privat, dan image terautentikasi dapat memerlukan batas berbeda walaupun memakai infrastruktur yang sama.

Terapkan kebijakan berdasarkan kelas resource

Header global dapat terasa praktis, tetapi kemudahan bukan model keamanan. Sebelum rollout, kelompokkan response berdasarkan audiens yang dituju.

Data akun privat, endpoint JSON internal, dan aset lokal origin merupakan kandidat same-origin ketika tidak ada kebutuhan cross-origin. Infrastruktur bersama dalam satu site dapat memakai same-site hanya jika seluruh origin yang berpartisipasi memang berada dalam batas trust. Aset CDN publik dapat memerlukan cross-origin ketika site lain memang menjadi konsumen yang diharapkan.

Inventaris route dapat direpresentasikan sebagai tabel kebijakan kecil:

/account/export/*     -> same-origin
/app-assets/*         -> same-origin
/shared-branding/*    -> same-site
/public-cdn/*         -> cross-origin

Pemetaan persisnya bergantung pada aplikasi. Properti pentingnya adalah setiap nilai mengikuti pola konsumsi yang terdokumentasi, bukan header menyeluruh yang disalin ke setiap response.

Pengujian kompatibilitas mencakup konsumen tidak langsung

Dependency cross-origin tidak selalu terlihat di repository aplikasi. Template email dapat mereferensikan image yang di-host. Halaman partner dapat menyematkan logo. Dokumentasi dapat memuat script atau media dari origin aset bersama. Rollout CORP yang restriktif dapat merusak konsumen tersebut walaupun aplikasi utama tetap berjalan.

Observasi karena itu perlu mencakup log request, kepemilikan aset, konfigurasi CDN, dan jalur integrasi yang diketahui. Pengujian perlu mencakup perilaku browser untuk elemen atau API yang benar-benar mengonsumsi setiap resource.

Distribusi PDF memerlukan perhatian tambahan. Implementasi browser pernah memiliki masalah kompatibilitas antara CORP dan rendering PDF, sehingga perubahan kebijakan produksi untuk response PDF perlu diuji terhadap kumpulan browser yang didukung layanan.

CORP merupakan satu lapisan isolasi

CORP memperkuat batas resource tanpa berubah menjadi mekanisme otorisasi. Response bertanda same-origin tetap dapat terekspos jika endpoint aplikasi mengembalikan data sensitif kepada pemanggil same-origin yang tidak berhak. Identitas dan otorisasi object pada server tetap menjadi otoritas utama.

Header ini juga tidak memperbaiki endpoint pengubah state yang tidak aman. Karena request dapat mencapai server sebelum browser memblokir pengiriman body, perlindungan pada sisi request tetap penting.

Dengan klasifikasi resource yang presisi, CORP memberi pemilik resource pernyataan yang ditegakkan browser mengenai konsumsi no-cors. Deployment yang kuat menjaga pernyataan tersebut tetap sempit, menguji jalur embedding yang sah, serta menggabungkannya dengan CORS, kontrol framing, pertahanan CSRF, COEP, dan otorisasi hanya ketika setiap mekanisme sesuai dengan batas yang dilindungi.