Apakah server saya diharapkan mengembalikan 200 untuk metode HTTP OPTIONS ketika titik koneksi dilarang untuk pengguna saat ini?

Membaca berbagai dokumentasi (seperti w3c CORS), saya harus mengatakan bahwa OPTIONS tidak sepertinya tidak terdokumentasi dengan baik sama sekali.

Saya bertanya-tanya apakah server REST saya melakukannya dengan benar, yaitu mengembalikan 403 jika klien mencoba mengakses titik koneksi yang dilarang (apakah itu ada atau tidak, itu tidak selalu menjadi masalah, meskipun kadang-kadang server dapat mengembalikan 404 alih-alih.)

Namun, dokumentasi OPTIONS tampaknya tidak menyimpulkan bahwa kode pengembalian tersebut valid.

Saya menemukan T/A stackoverflow ini di mana jawaban yang diterima sepertinya mengatakan bahwa kami dapat mengembalikan kode kesalahan apa pun.

Saya membayangkan itu akan menjadi lubang keamanan yang memungkinkan OPTIONS melewatinya ketika pengguna tidak diizinkan. Pada saat yang sama, OPTIONS mendefinisikan header Access-Control-Allow-Credentials dan saya tidak melihat bagaimana saya bisa membuat header itu berguna jika saya mengembalikan 403 pada titik koneksi tersebut. (Dengan kata lain, bagi saya hal itu terdengar kontradiktif.)


http rest cors http-method
person Alexis Wilke    schedule 29.01.2019    source sumber
comment
Dan sebenarnya jika saya mendeteksi 403 di sepanjang jalan, saya kemudian dapat membuat header Access-Control-Allow-Credentials pada saat itu.   -  person Alexis Wilke    schedule 29.01.2019

Jawaban (1)


arrow_upward
2
arrow_downward

Jawaban singkat: Jika Anda benar-benar ingin respons OPTIONS berguna sejauh mengaktifkan CORS pada server, maka Anda tidak boleh mengembalikan 403 hanya karena pengguna tidak masuk.

Detail:

Tidak ada salahnya server mengembalikan 403 untuk permintaan OPTIONS. Protokol CORS tidak mengharuskan server Anda mengembalikan respons 2xx sukses untuk permintaan OPTIONS. Namun jika server Anda tidak mengembalikan 2xx untuk OPTIONS permintaan ke URL tertentu, maka permintaan OPTIONS preflight CORS ke URL tersebut akan gagal. Jadi jika itu yang sebenarnya Anda inginkan terjadi, merespons dengan 403 tidak masalah — begitu juga merespons dengan 405 atau 501 atau kode respons lain apa pun yang mungkin memiliki arti yang sesuai dengan kasus khusus Anda.

Namun penting untuk diingat bahwa protokol CORS mengharuskan browser untuk tidak pernah mengirimkan kredensial autentikasi sebagai bagian dari permintaan preflight OPTIONS CORS. Jadi, jika server Anda dikonfigurasi untuk memerlukan autentikasi agar permintaan OPTIONS menghasilkan respons sukses 2xx, maka semua preflight CORS yang berasal dari browser akan gagal 100% sepanjang waktu. Dengan kata lain, Anda akan memastikan bahwa semua permintaan yang masuk ke server dari kode JavaScript frontend yang berjalan di browser akan gagal dan yang menambahkan header respons khusus (misalnya, header Content-Type atau Authorization) sehingga memicu preflight.

Saya tidak mengetahui adanya lubang keamanan spesifik yang dapat terjadi jika merespons dengan 2xx permintaan OPTIONS yang tidak diautentikasi (dari pengguna yang tidak diizinkan). Itu tidak mengizinkan pengguna mendapatkan informasi apa pun dari server Anda selain apa pun yang sengaja Anda masukkan ke dalam header respons yang Anda kirimkan sebagai respons terhadap permintaan OPTIONS. Dan tentu saja itu tidak menghalangi Anda untuk memerlukan otentikasi untuk GET atau POST atau metode apa pun lainnya. Namun dalam hal protokol CORS, ini adalah satu-satunya cara bagi server Anda untuk menunjukkan metode dan header permintaan apa yang diizinkan dalam permintaan dari JavaScript frontend.

Perhatikan juga: persyaratan CORS yang dipelihara secara aktif saat ini ditentukan dalam spesifikasi Ambil https://fetch.spec.whatwg.org. Spesifikasi https://w3.org/TR/cors sudah usang dan tidak lagi dipelihara dan tidak seharusnya tidak dapat digunakan untuk apa pun (lihat https://w3.org/2017/08/16-webappsec-menit.html#item03 dan jawabannya di https://stackoverflow.com/a/45926657/441757).

Saya tidak tahu mengapa spesifikasi https://w3.org/TR/cors tidak sudah jelas-jelas ditandai sebagai usang, tetapi saya akan mencoba memastikannya segera ditandai seperti itu.

person sideshowbarker    schedule 29.01.2019
comment
Ya, semoga berhasil mewujudkan itu. Terakhir saya dengar (dari @annevk), tidak ada seorang pun di W3 yang mau repot-repot menandainya sebagai usang, jadi hanya diam saja. Ingat, menurut saya dalam beberapa hal dokumen W3 ditulis lebih baik untuk pengembang front-end - spesifikasi Fetch benar-benar ditulis untuk pengembang browser... - person roryhewitt; 04.02.2019