Cross-Origin-Resource-Policy Mengendalikan Penyematan Resource
Server dapat memublikasikan image, script, font, atau resource lain pada sebuah URL tanpa bermaksud mengizinkan setiap site di web menyematkannya. Keterjangkauan jaringan saja tidak menyatakan batas tersebut. Browser dapat meminta resource meskipun same-origin policy tidak mengizinkan isi response dibuka ke JavaScript.
Cross-Origin-Resource-Policy (CORP) memberi server resource kontrol pada sisi response untuk kasus tersebut. Header ini memberi tahu browser pendukung hubungan apa antara konteks peminta dan resource yang dapat diterima untuk request no-CORS yang relevan. Jika hubungan tersebut melanggar kebijakan, browser memblokir penggunaan body response.
Cakupan CORP sengaja sempit. Mekanisme ini bukan autentikasi, bukan aturan otorisasi aplikasi, dan bukan pengganti CORS. Fungsinya adalah memberi pemilik resource kemampuan menolak hubungan penyematan yang jika tidak dibatasi masih diperbolehkan oleh pemuatan subresource biasa.
Kebijakan dibawa oleh response resource
Response dapat mendeklarasikan salah satu dari tiga nilai kebijakan:
Cross-Origin-Resource-Policy: same-originCross-Origin-Resource-Policy: same-siteCross-Origin-Resource-Policy: cross-originsame-origin adalah nilai paling ketat di antara ketiganya. Origin peminta harus sama dengan origin resource. Karena origin mencakup scheme, host, dan port, hostname saudara tidak otomatis termasuk same-origin.
same-site mengizinkan request yang origin-nya dianggap same-site menurut perhitungan site browser. Batas ini lebih luas daripada same-origin, sehingga pemilihannya tepat hanya jika origin saudara di dalam site tersebut memang merupakan konsumen yang dituju.
cross-origin secara eksplisit mengizinkan pemuatan cross-origin menurut CORP. Nilai ini dapat berguna ketika mekanisme isolasi browser lain mengharapkan kebijakan resource eksplisit sementara resource tersebut memang ditujukan untuk publik.
Header ini bernilai karena keputusan melekat pada response yang dilindungi. Halaman konsumen tidak dapat melonggarkan deklarasi same-origin atau same-site dari server resource hanya dengan menambahkan markup pada origin miliknya.
Same-origin dan same-site merupakan batas yang berbeda
Origin dan site adalah konsep browser yang berkaitan, tetapi keduanya tidak dapat dipertukarkan. Misalnya, sebuah resource disajikan dari static.example.com dan halaman berada di app.example.com. Kedua host tersebut merupakan origin yang berbeda. Bergantung pada scheme dan aturan registrable domain, keduanya masih dapat termasuk same-site.
Kebijakan same-origin pada static host karena itu memblokir pemuatan no-CORS dari application host meskipun kedua nama dimiliki organisasi yang sama. Kebijakan same-site dapat mengizinkan hubungan tersebut.
Perbedaan ini penting untuk deployment yang membagi aplikasi ke beberapa subdomain. Memilih same-site hanya karena tampak dekat dengan same-origin dapat memperluas trust boundary ke sibling host. Jika service dengan tingkat kepercayaan lebih rendah berbagi batas site tersebut, service itu dapat memperoleh hubungan penyematan yang akan ditolak oleh batas origin yang ketat.
Scheme juga berpengaruh pada perhitungan site browser modern. Deployment campuran HTTP dan HTTPS tidak sebaiknya mengasumsikan bahwa registrable domain yang sama selalu menghasilkan relasi same-site yang diinginkan. Pengujian perlu memakai scheme dan hostname yang benar-benar digunakan di production.
CORP dan CORS menjawab pertanyaan yang berbeda
CORS berpusat pada request cross-origin yang memerlukan izin agar response dapat dibagikan kepada origin peminta. Server memakai header seperti Access-Control-Allow-Origin untuk memberi izin tersebut pada fetch yang menggunakan CORS.
CORP menangani jalur berbeda: request subresource no-CORS yang relevan. Request semacam ini tetap dapat berguna bagi halaman meskipun JavaScript tidak dapat membaca byte response secara langsung. Image, misalnya, dapat dirender tanpa membuka body-nya kepada script.
Perbedaan ini penting dalam security review. Response yang tidak memiliki Access-Control-Allow-Origin belum tentu terlindungi dari penyematan cross-origin. Jika penyematan itu sendiri berada di luar trust boundary yang dituju, CORP dapat menyatakan pembatasan pada response resource.
Sebaliknya, CORP tidak memberi JavaScript akses ke response cross-origin. Menetapkan Cross-Origin-Resource-Policy: cross-origin tidak menggantikan CORS grant yang memang diperlukan. Kedua header mengikuti pemeriksaan browser yang berbeda.
Pemblokiran terjadi setelah request mungkin mencapai server
CORP tidak tepat diperlakukan sebagai network access control. Browser dapat mengirim request lalu menolak membuka atau menggunakan body response karena kebijakan tersebut. Server karena itu masih dapat melihat traffic dari konteks yang resource-nya kemudian diblokir oleh browser.
Sifat ini membuat CORP tidak cocok sebagai pertahanan bagi endpoint yang keamanannya bergantung pada request agar tidak pernah tiba. Autentikasi, otorisasi, pertahanan CSRF jika relevan, dan validasi request pada sisi server tetap diperlukan.
Ini juga berarti perubahan state yang sensitif tidak menjadi aman hanya karena response-nya membawa CORP. Endpoint HTTP tetap perlu mempertahankan semantik method yang benar dan menegakkan otorisasi secara independen dari penyaringan response oleh browser.
Isolasi cross-origin memberi CORP peran operasional kedua
CORP juga relevan bagi halaman yang menggunakan cross-origin isolation. Document yang dikonfigurasi dengan Cross-Origin-Embedder-Policy: require-corp menetapkan syarat lebih ketat bagi resource cross-origin yang dimuat ke document tersebut. Resource dapat memenuhi syarat penyematan melalui deklarasi CORP yang sesuai atau, untuk jenis request yang berlaku, melalui CORS.
Hal ini menciptakan dependency deployment antara document dan subresource-nya. Mengaktifkan cross-origin embedder policy sebelum mengaudit image, script, worker, font, dan asset pihak ketiga dapat membuat resource yang sebelumnya berhasil dimuat menjadi diblokir.
Kebijakan resource tetap perlu mencerminkan trust relationship yang sebenarnya. Menambahkan cross-origin ke semua resource hanya untuk menghilangkan kegagalan isolasi justru menghapus pembatasan yang seharusnya dapat diberikan CORP. Asset publik dan asset internal aplikasi sering memerlukan kebijakan yang berbeda.
Perilaku cache perlu mempertahankan batas yang sama
Cache dapat menyajikan representasi resource yang sama kepada beberapa peminta. CORP dibawa di dalam cached response, sehingga kebijakan yang stabil tetap dapat ditegakkan ketika response digunakan kembali oleh browser atau intermediary.
Masalah muncul ketika infrastruktur menghapus, menulis ulang, atau menyuntikkan security header secara tidak konsisten. Resource yang diuji langsung pada origin dapat berperilaku berbeda melalui CDN, reverse proxy, atau object-storage gateway jika response akhirnya tidak membawa kebijakan yang diharapkan.
Pemeriksaan deployment sebaiknya melihat response yang benar-benar diterima browser. Konfigurasi header merupakan bagian dari jalur delivery resource, bukan hanya bagian dari source code aplikasi.
Pemilihan kebijakan mengikuti kelompok konsumen yang dituju
Titik awal yang praktis adalah mengidentifikasi pihak yang boleh menyematkan setiap kelas resource. Asset yang hanya dipakai satu origin cocok dengan same-origin. Asset yang dibagi dengan sibling origin tepercaya dapat memakai same-site ketika batas site sesuai dengan trust boundary yang dituju. Resource untuk penyematan publik secara bebas dapat memakai cross-origin ketika deklarasi CORP eksplisit diperlukan.
Klasifikasi tersebut lebih presisi daripada menerapkan satu header ke setiap object dalam bucket atau distribusi CDN. Logo publik dan image internal aplikasi dapat berbagi infrastruktur storage sambil tetap memerlukan kebijakan browser yang berbeda.
CORP paling kuat ketika klaimnya tetap terbatas: browser harus menolak resource no-CORS yang sebenarnya dapat dimuat ketika peminta berada di luar hubungan yang dideklarasikan oleh response. Otorisasi sisi server tetap melindungi data, CORS tetap mengatur pembagian response cross-origin untuk request CORS, dan kebijakan isolasi document tetap menentukan syarat bagi halaman penyemat. Memisahkan batas-batas tersebut membuat kegagalan lebih mudah didiagnosis dan mencegah satu header diperlakukan sebagai model keamanan browser yang lengkap.