Cross-Origin-Resource-Policy Mengatur Embedding no-cors
Halaman web secara rutin menyematkan resource tanpa memberi JavaScript akses langsung ke byte responsnya. Gambar, classic script, media, dan subresource lain dapat memakai mode request no-cors, sehingga browser mengizinkan bentuk pemuatan lintas origin tertentu sambil menjaga respons tetap opaque bagi script.
Perilaku default itu berguna bagi web, tetapi pemilik resource dapat memerlukan batas yang lebih ketat. Cross-Origin-Resource-Policy (CORP) adalah header respons HTTP yang memberi tahu browser origin atau site mana yang boleh menggunakan respons melalui jalur no-cors yang dicakup policy ini.
Respons restriktif dapat membawa:
Cross-Origin-Resource-Policy: same-originHeader ini tidak mengubah endpoint privat menjadi publik, memberi akses CORS, atau menggantikan otorisasi di server. CORP adalah policy respons yang ditegakkan browser untuk kelas pemuatan resource tertentu.
CORP melekat pada resource
Server yang mengembalikan resource menetapkan CORP pada respons resource tersebut. Posisi ini membedakan CORP dari aturan tingkat dokumen yang mencantumkan tujuan yang boleh dihubungi sebuah halaman.
Nilai yang didefinisikan adalah:
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Resource-Policy: same-site
Cross-Origin-Resource-Policy: cross-originsame-origin mengizinkan penggunaan yang relevan ketika origin request dan origin resource sama. Perbandingan origin mencakup scheme, host, dan port.
same-site mengizinkan relasi yang lebih luas berdasarkan aturan same-site browser. Origin yang berbeda karena itu dapat tetap memenuhi syarat sebagai same-site. Perbedaan ini penting pada deployment yang memisahkan aplikasi dan aset statis di beberapa host yang saling terkait.
cross-origin mengizinkan penggunaan lintas origin untuk policy ini. Nilai tersebut cocok bagi resource yang memang dipublikasikan untuk embedding luas, termasuk resource yang perlu tetap tersedia bagi dokumen yang menerapkan embedder policy.
Pemilihan nilai merupakan pernyataan mengenai batas embedding yang dimaksudkan untuk resource, bukan urutan tingkat yang diterapkan secara mekanis ke setiap respons.
Policy bekerja pada respons no-cors
CORP relevan bagi request yang memakai mode no-cors. Contoh umum adalah gambar yang disematkan tanpa opt-in CORS:
<img src="https://media.example.net/account-badge.png" alt="">Jika respons dari media.example.net menyatakan:
Cross-Origin-Resource-Policy: same-origindokumen dari origin lain tidak dapat menggunakan respons itu melalui jalur no-cors yang dicakup. Browser menjalankan pemeriksaan CORP dan memblokir respons agar tidak diberikan untuk penggunaan tersebut.
Request jaringan sendiri mungkin sudah mencapai server. CORP tidak boleh dianggap sebagai mekanisme yang menjamin request tidak dikirim. Access control di server tetap bertanggung jawab menentukan apakah requester berhak menerima data sensitif.
Perbedaan ini juga berpengaruh pada logging dan analisis insiden. Server dapat mencatat request meskipun browser kemudian menolak memberikan respons kepada konteks yang melakukan embedding.
same-site lebih luas daripada same-origin
Pertimbangkan dua origin berikut:
https://app.example.com
https://static.example.comKeduanya merupakan origin berbeda karena host-nya berbeda. Bergantung pada perhitungan site yang berlaku, keduanya masih dapat termasuk same-site.
Resource yang hanya ditujukan bagi app.example.com tidak seharusnya memakai same-site hanya karena kedua host dimiliki satu organisasi. Jika origin lain dalam site yang sama memiliki tingkat kepercayaan lebih rendah, policy yang lebih luas dapat membuka relasi yang tidak dimaksudkan pemilik resource.
Untuk resource yang konsumennya benar-benar dibatasi pada origin yang sama, deklarasi yang lebih sempit bersifat langsung:
Cross-Origin-Resource-Policy: same-originUntuk infrastruktur yang sengaja dipakai bersama oleh beberapa origin dalam site yang sama, same-site dapat menyatakan arsitektur tersebut:
Cross-Origin-Resource-Policy: same-siteNilai yang tepat mengikuti batas kepercayaan yang sebenarnya.
CORP dan CORS menangani masalah berbeda
CORS mengatur apakah kode di browser dapat membuat request lintas origin tertentu dan mengakses responsnya. CORP memungkinkan respons resource membatasi penggunaan no-cors yang relevan.
API yang dirancang untuk akses JavaScript dari origin lain umumnya memerlukan policy CORS yang sesuai. Menambahkan CORP tidak menggantikan header seperti:
Access-Control-Allow-Origin: https://app.example.comSebaliknya, resource yang disematkan melalui jalur no-cors dapat dipengaruhi CORP meskipun kode aplikasi tidak pernah menerima respons CORS normal yang dapat dibaca.
Memisahkan kedua mekanisme ini mencegah kesalahan konfigurasi umum: menganggap setiap header lintas origin sebagai bentuk lain dari izin yang sama.
CORP ikut dalam penegakan COEP
Cross-Origin-Embedder-Policy: require-corp mengubah aturan embedding untuk sebuah dokumen. Dalam policy tersebut, resource lintas origin yang diminta dengan mode no-cors perlu memenuhi persyaratan CORP yang berlaku, sedangkan resource yang diminta dalam mode CORS diatur oleh CORS.
Sebuah dokumen dapat mengembalikan:
Cross-Origin-Embedder-Policy: require-corpdan aset publik lintas origin yang ditujukan bagi dokumen tersebut dapat mengembalikan:
Cross-Origin-Resource-Policy: cross-originKedua header menyatakan policy dari sisi berbeda. COEP melekat pada dokumen yang melakukan embedding; CORP melekat pada resource. Resource dengan demikian dapat menyatakan bahwa penggunaan no-cors lintas origin diperbolehkan, alih-alih membiarkan embedder mengasumsikan persetujuan.
CORP juga relevan di luar deployment COEP. Resource dapat mengirim nilai CORP restriktif secara mandiri.
Terapkan header sesuai kelas resource
Satu site dapat memiliki resource dengan kebutuhan eksposur yang sangat berbeda. Logo publik, gambar akun terautentikasi, laporan unduhan, script aplikasi, dan aset CDN bersama tidak selalu tepat ditempatkan di balik satu nilai CORP.
Deployment yang terarah dapat dimulai dengan mengelompokkan route resource:
/account/* -> penggunaan privat atau same-origin
/static/app/* -> aset yang dikendalikan aplikasi
/public/media/* -> aset yang sengaja dapat di-embedPemetaan tersebut bergantung pada aplikasi. Hal pentingnya adalah header mengikuti kelompok konsumen yang dimaksudkan, bukan kemudahan satu aturan middleware global.
Caching juga perlu diperhatikan. Jika intermediary dapat menyimpan respons yang berbeda berdasarkan otorisasi atau konten, CORP tidak memperbaiki cache key yang tidak aman. Autentikasi, otorisasi, cache control, dan CORP tetap merupakan lapisan terpisah.
Validasi perilaku pada batas browser
Keberadaan header saja belum membuktikan bahwa deployment sesuai dengan desainnya. Pengujian perlu menjalankan resource dari origin yang mewakili relasi yang memang diterima dan yang harus ditolak.
Untuk resource same-origin, kasus yang berguna mencakup:
origin sama -> diharapkan lolos batas CORP
site sama -> diharapkan gagal jika origin berbeda
lintas site -> diharapkan gagalUntuk resource publik yang sengaja membawa cross-origin, pengujian perlu memastikan embedding lintas origin tetap berfungsi pada mode request yang dimaksudkan.
Developer tools browser dapat menunjukkan pemuatan resource yang diblokir beserta header respons, sedangkan log server dapat memastikan apakah request mencapai origin. Melihat kedua sisi membantu membedakan pengiriman melalui jaringan dari penggunaan respons oleh browser.
CORP paling presisi ketika diperlakukan sebagai metadata resource dengan satu tugas sempit: menyatakan batas yang diizinkan bagi penggunaan respons no-cors yang relevan. Otorisasi tetap melindungi data di server, CORS tetap mengatur akses API lintas origin yang dapat dibaca, dan COEP tetap menentukan persyaratan dokumen yang melakukan embedding.