Apa itu 'CORS'? Untuk apa itu digunakan?

Cross origin Resource Sharing

Dorimouz

 Agustus 20, 2021·6 min read

 Apa itu CORS? Saya pikir. Untuk apa itu digunakan? Sebelum saya dapat mulai mengerjakan fitur ini, saya harus membangun pengetahuan tentang apa itu CORS.

“CORS” adalah singkatan dari Cross-Origin Resource Sharing. Ini memungkinkan Anda untuk membuat permintaan dari satu situs web ke situs web lain di browser, yang biasanya dilarang oleh kebijakan browser lain yang disebut Same-Origin Policy (SOP).

Penafian: Saya telah mengumpulkan informasi yang saya sajikan di sini dari campuran sumber daya yang sudah ada di web (tertaut di bagian bawah posting ini). Harap jangan ragu untuk mengoreksi atau mengklarifikasi informasi yang menyesatkan jika Anda menemukan kesalahpahaman!

Pengetahuan prasyarat:

Seperti apa permintaan HTTP

Pengetahuan yang bermanfaat:

Permintaan Javascript dan AJAX

Keakraban dengan API

Untuk memahami CORS, seseorang harus memahami Kebijakan Same-Origin.

Pada intinya, CORS dan SOP adalah kebijakan browser yang dikembangkan untuk menanggapi masalah keamanan dan kerentanan browser.

Kerentanan browser khusus yang dimaksudkan untuk ditangani oleh Same Origin Policy disebut "pemalsuan permintaan lintas situs" (CSRF, atau sebagai alternatif XSRF, bukankah Anda menyukai semua akronim ini?).

Sebelum browser menerapkan SOP, situs web jahat dapat mengeksploitasi cookie (lihat: apa itu cookie? di sini) yang disimpan oleh browser Anda untuk membuat permintaan tidak sah ke domain lain. Beberapa permintaan tidak sah ini dapat melakukan hal-hal seperti melakukan pembelian, menghapus informasi pengguna, mengambil data sensitif, dll.

Sebagai contoh, Anda dapat membuka situs web perbankan dan memberikan beberapa kredensial untuk masuk ke akun Anda. Nama pengguna Anda disimpan dalam cookie browser yang aman untuk jangka waktu tertentu sehingga bank dapat memberi tahu Anda bahwa Anda masih login daripada meminta Anda login lain kali dengan setiap halaman yang Anda akses. Itu bagus!

Kemudian, Anda pergi ke halaman web yang tampak tidak bersalah yang mencantumkan beberapa fakta tentang kelinci. Tanpa sepengetahuan Anda, HTML halaman web juga memiliki sedikit skrip Javascript untuk membuat permintaan AJAX (lihat: XMLHttpRequest) ke situs web perbankan sebelumnya untuk melakukan transaksi kawat ke akun lain. Karena sesi Anda masih diautentikasi dengan cookie yang disimpan sebelumnya, situs web perbankan menganggap Anda hanya mengklik tautan di situs mereka untuk mengirimkan transaksi kawat. Oh tidak!

Perbaikan mudahnya adalah agar browser mendeteksi saat permintaan dibuat dari satu situs web ke situs web lain dan mencegah respons agar tidak dapat dibaca. Ini adalah Kebijakan Asal yang Sama.

Tunggu sebentar, bagaimana saya bisa memuat gambar dari situs web lain sendiri?

Anda mungkin tahu bahwa memuat gambar dari situs lain dan menyematkan konten lain di halaman web Anda memerlukan browser untuk mengirim permintaan GET untuk mengambil data dari server web lain, dan tidak mengalami masalah dalam melakukan hal ini.

Tidak seperti permintaan AJAX, browser mengizinkan penyematan sebagian besar konten dari situs web lain, seperti gambar, tag skrip, css, dll, secara default. Beberapa kemungkinan pengecualian adalah iframe, bergantung pada konfigurasi situs, dan font, bergantung pada browser.

Ini membuat jalan serangan terbuka untuk serangan CSRF/XSRF, karena Anda dapat menggunakan <img src='…'/> untuk membuat permintaan GET berbahaya ke situs web lain daripada memuat gambar. Ini berarti server harus melakukan beberapa pekerjaan tambahan untuk menerapkan keamanan, dengan menggunakan token CSRF atau tiket transaksi, jika permintaan GET dapat mengakibatkan efek samping yang tidak diinginkan atau mengungkapkan informasi rahasia. Baca lebih lanjut di sini: https://stackoverflow.com/a/29167709 dan https://stackoverflow.com/a/27294846 (di mana Token CRSF dicetak tebal).

Jadi bagaimana jika saya ingin membuat permintaan AJAX ke API luar di skrip browser?

Sebaliknya, bagaimana jika Anda mengembangkan API dan Anda ingin mengizinkan orang membuat permintaan AJAX (atau API web yang lebih baru seperti Fetch) ke API Anda di browser? Atau lebih sederhananya, Anda ingin memastikan siapa pun dapat mengakses font yang Anda bagikan dari situs web Anda, apa pun browser mereka?

Akhirnya, kami tiba di CORS.

CORS memungkinkan server untuk menentukan 'asal' tepercaya tertentu yang bersedia mereka izinkan permintaannya. Asal didefinisikan sebagai kombinasi protokol (http atau https), host (domain seperti www.example.com atau alamat IP) dan port. Browser yang menerapkan kebijakan CORS akan menyertakan header HTTP yang disebut 'Origin' dalam permintaan yang dibuat dengan AJAX, termasuk informasi di atas nilainya.

Permintaan sederhana

Untuk menginstruksikan browser untuk mengekspos respons server ke permintaan HTTP dari asal tertentu, server web harus menanggapi permintaan dengan header respons HTTP tambahan, 'Access-Control-Allow-Origin: <origin>’. Atau, server web dapat mengekspos responsnya ke semua asal dengan menentukan nilai '*', mis. 'Access-Control-Allow-Origin: *'.

Sederhana, ya?

Permintaan pra-penerbangan

Ini mungkin cukup untuk permintaan GET, HEAD, atau POST sederhana tanpa header http khusus. Namun, untuk permintaan DELETE dan PUT, permintaan 'tidak aman' yang dapat memengaruhi data server, atau permintaan GET, HEAD dan POST dengan header yang disesuaikan, browser akan mengirimkan permintaan "preflight" untuk mengetahui hasil CORS sebelum mengirim yang sebenarnya permintaan (hanya jika respons sebelum penerbangan menentukan akses diizinkan).

Permintaan preflight adalah permintaan OPSI yang dibuat ke jalur HTTP yang sama dengan permintaan sebenarnya, dengan beberapa header HTTP:

Asal — Header asal yang akan disertakan dengan permintaan aktual yang dibuat oleh situs web.

Access-Control-Request-Method — Metode permintaan aktual yang dibuat oleh situs web.

Access-Control-Request-Headers — Daftar header yang dipisahkan koma yang akan disertakan dalam permintaan sebenarnya.

Server web yang ingin mendukung permintaan CORS harus menanggapi permintaan preflight dengan header HTTP berikut:

Access-Control-Allow-Origin — Asal yang masuk daftar putih, atau '*'

Access-Control-Allow-Methods — Daftar metode HTTP yang dipisahkan koma yang ingin diizinkan oleh server web untuk permintaan lintas-asal

Access-Control-Allow-Headers — Daftar header HTTP yang dipisahkan koma yang ingin diizinkan oleh server web untuk permintaan lintas-asal

Jika ada informasi di header respons yang tidak cocok dengan parameter permintaan yang sebenarnya, browser tidak akan mengirim permintaan yang sebenarnya, mencegah efek samping yang tidak diinginkan dari server yang menerima permintaan lintas asal. (Lagi pula, termasuk 'Access-Control-Allow-Origin' dalam menanggapi permintaan lain tidak mencegah permintaan tersebut dibuat ke server; itu hanya mencegah browser menampilkan respons.)

Ada lebih banyak header CORS yang dapat ditanggapi oleh server, termasuk 'Access-Control-Expose-Headers', 'Access-Control-Max-Age', dan 'Access-Control-Allow-Credentials'. Daripada membahas terlalu banyak detail, saya akan mendorong Anda untuk melihat artikel terperinci MDN tentang CORS (contoh permintaan/tanggapan HTTP disertakan!) dan arti dari setiap tajuk.

Tetapi bagaimana jika saya menggunakan API, bukan mengembangkannya?

Anda mungkin memperhatikan semua hal di atas terkait dengan respons yang harus dikirim dari sisi server. Biasanya, browser atau SDK browser Anda akan mengirimkan header permintaan Asal dan membuat permintaan preflight untuk Anda saat Anda membuat permintaan AJAX.

Sebagai gantinya, Anda mungkin perlu mengonfigurasi layanan yang Anda gunakan untuk mengizinkan Asal Anda, daftar asal, atau semua asal. Sebagai contoh, Zenko CloudServer, yang mengikuti Protokol S3 Amazon, memaparkan metode API (Put Bucket CORS) yang dapat Anda gunakan untuk mengonfigurasi bucket dengan konfigurasi CORS dengan aturan CORS yang digunakan untuk menentukan respons server terhadap permintaan CORS. (Ini adalah fitur yang saya kerjakan yang saya sebutkan di awal artikel.)

Saya mungkin memperbarui artikel ini nanti dengan panduan untuk menggunakan Put Bucket CORS dengan Zenko CloudServer jika contohnya membantu, tetapi karena artikel ini ditujukan untuk pengembang junior, saya pikir akan sangat membantu untuk memahami bagaimana CORS secara keseluruhan bekerja di kasus apapun.

Penutupan:

Saya harap Penjelasan Saya membantu Kalian buat memahami apa itu CORS 

Segitu ajh dari saya Assallamuallaikum wr.wb