Selamat siang teman!
Untuk perhatian Anda saya persembahkan terjemahan dari artikel "CS Visualized: CORS" oleh Lydia Hallie.
Setiap pengembang harus berurusan dengan kesalahan
Access to fetched has been blocked by CORS policy. Ada beberapa cara untuk mengatasi masalah ini dengan cepat. Namun, mari luangkan waktu kita dan lihat lebih dekat apa itu kebijakan CORS.
Kami sering kali perlu menampilkan data yang ada di tempat lain. Sebelum kita dapat melakukan ini, browser harus mengirim permintaan ke server untuk menerima data ini.
Katakanlah kami ingin mendapatkan informasi tentang pengguna di situs kami
www.mywebsite.comdari server yang terletak di situs api.website.com.
Luar biasa! Kami baru saja mengirim permintaan ke server dan menerima data JSON sebagai imbalan.
Sekarang mari kita coba mengirim permintaan serupa ke domain lain. Alih-alih mengirim permintaan dengan, mari kita
www.mywebsite.comkirimkan dengan www.anotherdomain.com.
Apa yang terjadi? Kami mengirimkan permintaan yang sama persis, tetapi kali ini browser menunjukkan beberapa jenis kesalahan.
Kami melihat CORS beraksi. Mengapa kesalahan ini terjadi dan apa artinya?
Kebijakan asal umum
Ada sesuatu di web yang disebut Kebijakan Asal Generik (selanjutnya disebut POP). Secara default, kami hanya memiliki akses ke sumber daya yang memiliki asal yang sama dengan asal permintaan kami. Misalnya, kita dapat memuat gambar yang terletak di
https://mywebsite.com/image1.png.
Sumber berbeda jika terletak di (sub) domain, protokol, atau port yang berbeda.
Keren, tapi kenapa butuh POP?
Katakanlah itu tidak ada, dan Anda secara tidak sengaja mengklik tautan viral yang diposting oleh bibi Anda di Facebook. Tautan ini mengarahkan Anda ke "situs jahat" yang memiliki iframe tertanam yang memuat situs bank Anda dan berhasil masuk ke sana menggunakan cookie.
Pengembang "situs jahat" memastikan bahwa dia memiliki akses ke iframe dan dapat berinteraksi dengan konten DOM situs bank Anda untuk mentransfer dana ke akunnya atas nama Anda.
Ya ... ini adalah masalah keamanan yang serius. Kami tidak ingin siapa pun memiliki akses ke apa pun tanpa sepengetahuan kami.
Untungnya, ada EPP. Kebijakan ini membatasi akses ke sumber daya dari sumber lain.
Dalam kasus ini, sumber
www.evilwebsite.commencoba mengakses sumber daya dari sumber www.bank.com. EPP memblokir akses ini dan melarang pengembang situs jahat mengakses data perbankan Anda.
Oke, tapi ... bagaimana cara kerjanya?
CORS sisi klien
Meskipun EPP hanya berlaku untuk skrip, browser "memperluas" ke permintaan JavaScript apa pun: secara default, kami hanya memiliki akses ke sumber daya dari satu sumber.
Hmm, tapi ... seringkali kita perlu mendapatkan sumber daya dari sumber lain. Mungkin frontend kita perlu pergi ke API server untuk memuat data. Untuk mengambil sumber daya dari sumber lain dengan aman, browser menerapkan mekanisme yang disebut CORS.
CORS adalah singkatan dari Cross-Origin Resource Sharing. Meskipun browser melarang sumber daya dari sumber lain, kami dapat menggunakan CORS untuk mengubah batasan ini sambil tetap aman.
Agen pengguna (browser) dapat menggunakan CORS untuk mengizinkan permintaan lintas sumber yang jika tidak akan diblokir berdasarkan beberapa header tanggapan HTTP.
Saat permintaan dibuat ke sumber lain, klien secara otomatis menambahkan header ke permintaan HTTP
Origin. Nilai tajuk ini adalah sumber permintaan.
Agar browser mengizinkan mengambil sumber daya dari sumber lain, respons server juga harus berisi header tertentu.
CORS sisi server
Sebagai pengembang backend, kami dapat mengizinkan sumber lain untuk mendapatkan sumber daya kami dengan menyertakan tajuk khusus yang dimulai dengan
Access-Control-*. Berdasarkan nilai header tersebut, browser memungkinkan berbagi sumber daya.
Ada beberapa CORS-header, tapi salah satu dari mereka adalah suatu keharusan:
Access-Control-Allow-Origin.
Arti tajuk ini menentukan sumber mana yang dapat diterima sumber daya kami.
Jika kami mengembangkan server yang perlu diakses
https://mywebsite.com, kami harus menambahkan domain ini ke header Access-Control-Allow-Origin.
Bagus. Header ini sekarang ditambahkan ke respons server yang dikirim ke klien. EPP tidak lagi mencegah kami menerima sumber daya
https://api.mywebsite.commelalui permintaan yang dikirim dari https://mywebsite.com.
Browser CORS memeriksa apakah
Access-Control-Allow-Originheader respons dan header permintaan cocok Origin.
Dalam kasus ini, sumber permintaan kami adalah
https://www.mywebsite.comheader respons yang ditentukan dalam daftar Access-Control-Allow-Origin.
Luar biasa. Sekarang kita bisa mendapatkan sumber daya dari sumber lain. Apa yang terjadi jika kami mencoba melakukan ini dari sumber yang tidak terdaftar di
Access-Control-Allow-Origin?
Ya, CORS telah memblokir akses ke sumber daya.
The 'Access-Control-Allow-Origin' header has a value
'https://www.mywebsite.com' that is not equal
to the supplied origin.
Dalam kasus ini, sumber
https://www.anotherwebsite.comtidak terdaftar di Access-Control-Allow-Origin. CORS berhasil menolak data yang diminta.
CORS memungkinkan Anda menentukan
*sumber yang diizinkan sebagai nilai. Artinya, sumber daya akan tersedia untuk sumber mana pun, jadi berhati-hatilah.
Access-Control-Allow-OriginMerupakan salah satu dari sekian banyak judul yang dapat kami atur. Pengembang back-end dapat mengonfigurasi CORS untuk mengizinkan (menolak) permintaan khusus.
Judul umum lainnya adalah
Access-Control-Allow-Methods. CORS hanya mengizinkan permintaan dari sumber lain yang dikirim menggunakan metode yang ditentukan.
Dalam kasus ini, hanya permintaan yang dikirim menggunakan metode GET, POST atau PUT yang diperbolehkan. Metode lain seperti PATCH atau DELETE akan diblokir.
CORS memperlakukannya dengan cara khusus ketika datang ke permintaan yang dikirim menggunakan metode PUT, PATCH, dan DELETE. Kueri "rumit" ini terkadang disebut sebagai kueri preflight.
Permintaan pendahuluan
CORS bekerja dengan dua jenis permintaan: sederhana dan sementara. Apa kueri itu bergantung pada beberapa nilainya.
Permintaan sederhana jika dikirim menggunakan metode GET atau POST dan tidak berisi header tambahan. Permintaan lainnya bersifat pendahuluan.
Oke, tapi apa artinya pra-permintaan dan mengapa permintaan seperti itu diperlukan?
Sebelum mengirim permintaan sebenarnya, klien mengirimkan permintaan awal ke server dengan informasi tentang permintaan sebenarnya: tentang metodenya, header tambahan, termasuk
Access-Control-Request-*, dll.
Server menerima permintaan sementara dan mengirimkan respons sementara kosong yang berisi header CORS. Browser menerima respon sementara dan memeriksa apakah permintaan sebenarnya akan diizinkan.
Jika demikian, maka browser mengirimkan permintaan sebenarnya dan menerima data sebagai tanggapan.
Jika tidak, CORS akan memblokir permintaan di muka dan permintaan sebenarnya tidak akan dikirim. Permintaan preemptif adalah cara terbaik untuk mencegah sumber daya diakses dan dimodifikasi di server. Ini melindungi server dari permintaan yang mungkin tidak diinginkan dari sumber lain.
Untuk mengurangi jumlah permintaan berulang, kita dapat menyimpan respons sementara dengan menambahkan header
Access-Control-Max-Ageke permintaan CORS. Ini untuk menghindari pengiriman ulang permintaan awal.
Kredensial
Cookie, header otorisasi, dan sertifikat TLS dipasang secara default hanya untuk permintaan dari satu sumber. Namun, kami mungkin perlu menggunakan otoritas ini dalam permintaan dari sumber lain. Mungkin kami ingin menyertakan cookie dalam permintaan yang dapat digunakan server untuk mengidentifikasi pengguna.
Meskipun CORS tidak berisi izin secara default, kami dapat mengubahnya dengan header
Access-Control-Allow-Credentials.
Jika kami ingin menyertakan cookie dan header otorisasi lainnya dalam permintaan kami dari sumber lain, kami perlu menyetel bidang ke
withCredentialsnilai truedalam permintaan dan menambahkan header Access-Control-Allow-Credentialske respons.
Selesai, sekarang kita bisa memasukkan kredensial dalam permintaan kita dari sumber lain.
Saya harap artikel ini bermanfaat bagi Anda. Terima kasih atas perhatian Anda.