Topik temu duga representatif

Temu duga Backend: Bagaimanakah anda akan menggunakan penapis CORS HTTPRoute Kubernetes Gateway API?

BackendSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Beberapa frontend mengakses perkhidmatan backend yang berbeza melalui Kubernetes Gateway. Terangkan bagaimana anda akan mengkonfigurasi CORS dalam HTTPRoute, mengendalikan preflight dan kelayakan, serta mengesahkan bahawa pelaksanaan Gateway yang berbeza tidak memberikan akses silang asal (cross-origin) yang terlalu luas.

Gesaan dan konteks

Gateway API v1.5 telah memindahkan penapis CORS HTTPRoute ke saluran Standard. Ia membolehkan peraturan laluan mengisytiharkan asal (origins), kaedah, pengepala permintaan, pengepala terdedah, dan masa cache preflight yang dibenarkan. Soalan ini menguji sama ada anda boleh meletakkan dasar silang asal pada sempadan gateway yang betul sambil mengekalkan kebenaran pelayan dan pengesahan khusus pelaksanaan.

Perkara yang dinilai oleh penemu duga

Penemu duga mencari perbezaan antara perlindungan CORS pelayar, pengepala respons gateway, dan kebenaran identiti sebenar. Jawapan yang kukuh merangkumi laluan preflight OPTIONS, kelayakan dan asal, risiko wildcard, keistimewaan paling sedikit (least privilege) bagi setiap laluan, dan sama ada pelaksanaan Gateway menyokong penapis tersebut. Menulis allowOrigins: "*" semata-mata tidak menunjukkan reka bentuk yang selamat.

Soalan untuk dijelaskan sebelum menjawab

Asal dan sumber manakah yang memerlukan akses silang asal?

Senaraikan asal pengeluaran, pratonton (preview), pentadbiran, dan pembangunan tempatan, kemudian berikan kebenaran bagi setiap laluan dan bukannya merentasi keseluruhan domain. Senarai tersebut mestilah boleh diaudit dan mempunyai tempoh tamat, dengan asal ujian diasingkan daripada persekitaran pengeluaran.

Adakah kelayakan disertakan?

Sahkan sama ada permintaan membawa kuki, pengesahan HTTP, atau kelayakan lain. Permintaan yang disertakan kelayakan memerlukan dasar asal dan pengepala respons yang lebih ketat; asal sewenang-wenangnya tidak boleh digabungkan dengan kelayakan secara lalai.

Siapakah pemilik kebenaran dan pelepasan dasar?

Tentukan tanggungjawab Gateway, aplikasi, dan perkhidmatan identiti. CORS mengawal sama ada skrip pelayar boleh membaca respons; ia tidak menggantikan pengesahan token, pengasingan penyewa (tenant), atau kebenaran sumber.

Kerangka jawapan 30 saat

“Saya terlebih dahulu mengehadkan skop asal mengikut HTTPRoute dan sumber perniagaan dan bukannya meluaskannya ke seluruh Gateway. Bagi setiap laluan, saya menentukan asal, kaedah, pengepala, pengepala terdedah, dan maxAge; laluan berkelayakan menggunakan asal yang telah disemak dan pengepala respons yang disahkan. Saya menguji preflight OPTIONS, permintaan sebenar, ralat, dan penamatan tempoh cache, serta mengesahkan pelaksanaan Gateway menyokong penapis tersebut. Akhir sekali, saya mengesahkan CORS sebagai sempadan akses pelayar secara berasingan daripada kebenaran pelayan, audit, dan rollback.”

Jawapan mendalam langkah demi langkah

Langkah 1: Bina keistimewaan paling sedikit bagi setiap laluan

Rekodkan sumber, asal, kaedah yang dibenarkan, dan keperluan pengepala bagi setiap HTTPRoute. Sumber baca sahaja awam dan sumber akaun berkelayakan harus menggunakan peraturan yang berasingan supaya satu dasar yang permisif tidak merangkumi keseluruhan domain.

Langkah 2: Konfigurasikan medan penapis

Tetapkan allowOrigins, allowMethods, allowHeaders, exposeHeaders, dan maxAge daripada keperluan sebenar. Semak corak asal terhadap dokumentasi pelaksanaan dan dasar keselamatan; utamakan asal eksplisit berbanding penggunaan wildcard yang tidak perlu.

Langkah 3: Kendalikan preflight dengan betul

Pelayar menghantar OPTIONS dengan Origin, Access-Control-Request-Method, dan kemungkinan Access-Control-Request-Headers. Gateway mesti mengembalikan pengepala CORS yang konsisten dengan dasar dan menolak permintaan yang tidak dibenarkan secara jelas dan bukannya memajukan preflight ke backend yang tidak memahami CORS.

Langkah 4: Asingkan kelayakan dan kebenaran

Reka bentuk tingkah laku kelayakan dengan atribut kuki, perlindungan CSRF, pengesahan token, dan kebenaran pelayan. Walaupun pelayar menyekat akses skrip, pelayan itu sendiri mesti membenarkan permintaan tersebut.

Langkah 5: Sahkan pelaksanaan dan rollback

Sahkan bahawa pengawal Gateway menyokong penapis CORS Standard v1.5 dan semantik medannya. Buat semula preflight, permintaan sebenar, kegagalan, pengalihan, dan tingkah laku cache menggunakan pelayar dan curl; rekodkan perubahan dasar, metrik, dan langkah-langkah rollback.

Contoh jawapan berkualiti tinggi

Saya akan mengehadkan skop asal bagi setiap HTTPRoute, memastikan antara muka carian awam diasingkan daripada antara muka akaun berkelayakan. Setiap peraturan akan menentukan asal, kaedah, pengepala permintaan, pengepala terdedah, dan masa cache preflight yang dibenarkan; akses berkelayakan hanya akan menggunakan asal pengeluaran yang telah disemak. Sebelum pelepasan, saya akan menguji OPTIONS dan permintaan sebenar dalam pelayar, termasuk ralat, pengalihan, dan penamatan tempoh cache, kemudian menggunakan curl dan syarat status (status conditions) pengawal Gateway untuk mengesahkan konfigurasi aktif. CORS hanya mentakrifkan sempadan bacaan pelayar; pelayan tetap menguatkuasakan kebenaran identiti, penyewa, dan sumber. Sebarang perbezaan semantik pengawal akan dijejaki dalam matriks keserasian dengan sandaran (fallback) pada lapisan aplikasi.

Kesilapan biasa

  • Kesilapan: Membenarkan setiap asal secara global. → Sebab ia gagal: Mana-mana laluan boleh dibaca oleh skrip pelayar, menyukarkan audit dan pembatalan. → Penyelesaian: Bina set asal terkecil bagi setiap HTTPRoute.
  • Kesilapan: Mengkonfigurasi permintaan sebenar sahaja dan mengabaikan OPTIONS. → Sebab ia gagal: Kaedah atau pengepala kompleks disekat oleh preflight terlebih dahulu. → Penyelesaian: Uji preflight dan respons sebenar secara berasingan.
  • Kesilapan: Menganggap CORS sebagai kebenaran (authorization). → Sebab ia gagal: Klien bukan pelayar masih boleh memanggil perkhidmatan secara terus. → Penyelesaian: Kekalkan pemeriksaan identiti, penyewa, dan sumber pada pelayan.
  • Kesilapan: Melancarkan medan v1.5 tanpa menguji pengawal. → Sebab ia gagal: Pelaksanaan mungkin mengabaikan, menolak, atau mentafsirkannya secara berbeza. → Penyelesaian: Semak matriks sokongan, syarat status, dan main semula trafik sebenar.

Soalan susulan dan respons

Soalan susulan 1: Mengapa tidak menetapkan CORS dalam aplikasi sahaja?

Aplikasi boleh memiliki dasar khusus sumber, manakala Gateway boleh mengendalikan preflight peringkat laluan dan sempadan rentas perkhidmatan. Apabila kedua-dua lapisan menetapkan pengepala, tentukan keutamaan untuk mengelakkan pertindihan atau konflik.

Soalan susulan 2: Patutkah maxAge sentiasa ditetapkan selama yang mungkin?

Tidak. Cache preflight yang lebih lama mengurangkan trafik OPTIONS tetapi melambatkan pembatalan. Pilihlah berdasarkan kekerapan perubahan, risiko, dan tingkah laku pelayar, serta sediakan laluan asal berversi (versioned-origin) atau TTL pendek untuk penarikan balik yang mendesak.

Soalan susulan 3: Bilakah asal wildcard boleh diterima?

Hanya untuk sumber yang benar-benar awam tanpa kelayakan dan dengan penilaian risiko yang diluluskan. Data akaun, pentadbiran, dan penyewa harus menggunakan asal eksplisit dan tingkah laku wildcard yang telah diuji.

Soalan susulan 4: Bagaimanakah anda mengesan asal yang dibenarkan secara tidak sengaja?

Log Origin, laluan, hasil preflight, dan versi dasar; audit perubahan asal. Jalankan matriks automatik daripada asal yang dibenarkan, tidak dibenarkan, dan tamat tempoh, serta sekat pelepasan apabila pengepala respons menyimpang daripada dasar.

Sumber awam

Soalan berkaitan