Pertanyaan dan konteks
Gateway API v1.5 memindahkan filter CORS HTTPRoute ke saluran Standard. Fitur ini memungkinkan aturan rute mendeklarasikan origin, metode, header permintaan, header yang diekspos, dan waktu cache preflight yang diizinkan. Pertanyaan ini menguji apakah Anda dapat menempatkan kebijakan cross-origin pada batas gateway yang tepat sambil tetap mempertahankan otorisasi server dan verifikasi khusus implementasi.
Hal yang dinilai oleh pewawancara
Pewawancara mencari pemahaman pembeda antara proteksi CORS browser, header respons gateway, dan otorisasi identitas yang sebenarnya. Jawaban yang kuat mencakup jalur preflight OPTIONS, kredensial dan origin, risiko wildcard, hak istimewa terendah (least privilege) per rute, dan apakah implementasi Gateway mendukung filter tersebut. Hanya menulis allowOrigins: "*" tidak menunjukkan desain yang aman.
Pertanyaan untuk diklarifikasi sebelum menjawab
Origin dan sumber daya mana yang membutuhkan akses cross-origin?
Buat daftar origin produksi, pratinjau (preview), administrasi, dan pengembangan lokal, lalu otorisasi per rute alih-alih untuk seluruh domain. Daftar tersebut harus dapat diaudit dan memiliki masa kedaluwarsa, dengan origin pengujian dijauhkan dari produksi.
Apakah kredensial disertakan?
Konfirmasikan apakah permintaan membawa cookie, autentikasi HTTP, atau kredensial lainnya. Permintaan berkredensial memerlukan kebijakan origin dan header respons yang lebih ketat; origin arbitrer tidak boleh digabungkan dengan kredensial secara default.
Siapa yang bertanggung jawab atas otorisasi dan rilis kebijakan?
Tentukan tanggung jawab Gateway, aplikasi, dan layanan identitas. CORS mengontrol apakah skrip browser dapat membaca respons; ini tidak menggantikan validasi token, isolasi tenant, atau otorisasi sumber daya.
Kerangka jawaban 30 detik
“Pertama, saya membatasi cakupan origin berdasarkan HTTPRoute dan sumber daya bisnis alih-alih memperluas seluruh Gateway. Untuk setiap rute, saya menentukan origin, metode, header, header yang diekspos, dan maxAge; rute berkredensial menggunakan origin yang telah ditinjau dan header respons yang terverifikasi. Saya menguji preflight OPTIONS, permintaan sebenarnya, kesalahan, dan kedaluwarsa cache, serta mengonfirmasi bahwa implementasi Gateway mendukung filter tersebut. Terakhir, saya memverifikasi CORS sebagai batas akses browser secara terpisah dari otorisasi server, audit, dan rollback.”
Jawaban mendalam langkah demi langkah
Langkah 1: Buat hak istimewa terendah per rute
Catat sumber daya, origin, metode yang diizinkan, dan kebutuhan header untuk setiap HTTPRoute. Sumber daya publik hanya-baca dan sumber daya akun berkredensial harus menggunakan aturan terpisah sehingga satu kebijakan yang permisif tidak mencakup seluruh domain.
Langkah 2: Konfigurasikan field filter
Atur allowOrigins, allowMethods, allowHeaders, exposeHeaders, dan maxAge berdasarkan kebutuhan sebenarnya. Tinjau pola origin terhadap dokumentasi implementasi dan kebijakan keamanan; utamakan origin eksplisit daripada wildcard yang tidak perlu.
Langkah 3: Tangani preflight dengan benar
Browser mengirimkan OPTIONS dengan Origin, Access-Control-Request-Method, dan kemungkinan Access-Control-Request-Headers. Gateway harus mengembalikan header CORS yang konsisten dengan kebijakan dan secara tegas menolak permintaan yang tidak diizinkan alih-alih meneruskan preflight ke backend yang tidak memahami CORS.
Langkah 4: Pisahkan kredensial dan otorisasi
Rancang perilaku kredensial dengan atribut cookie, proteksi CSRF, validasi token, dan otorisasi server. Meskipun browser memblokir akses skrip, server itu sendiri harus mengotorisasi permintaan tersebut.
Langkah 5: Verifikasi implementasi dan rollback
Konfirmasikan bahwa pengontrol Gateway mendukung filter CORS Standard v1.5 beserta semantik field-nya. Reproduksi preflight, permintaan sebenarnya, kegagalan, pengalihan, dan perilaku cache menggunakan browser dan curl; catat perubahan kebijakan, metrik, dan langkah-langkah rollback.
Contoh jawaban berkualitas tinggi
Saya akan membatasi cakupan origin per HTTPRoute, memisahkan antarmuka pencarian publik dari antarmuka akun berkredensial. Setiap aturan akan menentukan origin, metode, header permintaan, header yang diekspos, dan waktu cache preflight yang diizinkan; akses berkredensial hanya akan menggunakan origin produksi yang telah ditinjau. Sebelum rilis, saya akan menguji OPTIONS dan permintaan sebenarnya di browser, termasuk kesalahan, pengalihan, dan kedaluwarsa cache, kemudian menggunakan curl serta kondisi status (status conditions) pengontrol Gateway untuk memastikan konfigurasi aktif. CORS hanya menentukan batas pembacaan oleh browser; server tetap menegakkan otorisasi identitas, tenant, dan sumber daya. Setiap perbedaan semantik pengontrol akan dilacak dalam matriks kompatibilitas dengan fallback pada lapisan aplikasi.
Kesalahan umum
- Kesalahan: Mengizinkan setiap origin secara global. → Mengapa ini gagal: Rute apa pun dapat dibaca oleh skrip browser, membuat audit dan pencabutan menjadi sulit. → Perbaikan: Bangun set origin terkecil per HTTPRoute.
- Kesalahan: Hanya mengonfigurasi permintaan sebenarnya dan mengabaikan OPTIONS. → Mengapa ini gagal: Metode atau header yang kompleks diblokir terlebih dahulu oleh preflight. → Perbaikan: Uji preflight dan respons sebenarnya secara terpisah.
- Kesalahan: Memperlakukan CORS sebagai otorisasi. → Mengapa ini gagal: Klien non-browser masih dapat memanggil layanan secara langsung. → Perbaikan: Pertahankan pemeriksaan identitas, tenant, dan sumber daya di sisi server.
- Kesalahan: Merilis field v1.5 tanpa menguji pengontrol. → Mengapa ini gagal: Implementasi mungkin mengabaikan, menolak, atau menafsirkannya secara berbeda. → Perbaikan: Periksa matriks dukungan, kondisi status, dan pemutaran ulang lalu lintas nyata.
Pertanyaan lanjutan dan respons
Pertanyaan lanjutan 1: Mengapa tidak menyetel CORS hanya di aplikasi?
Aplikasi dapat memiliki kebijakan khusus sumber daya, sedangkan Gateway dapat menangani preflight tingkat rute dan batasan lintas layanan. Ketika kedua lapisan menetapkan header, tentukan prioritasnya untuk menghindari duplikasi atau konflik.
Pertanyaan lanjutan 2: Haruskah maxAge selalu dibuat sepanjang mungkin?
Tidak. Cache preflight yang lebih lama mengurangi lalu lintas OPTIONS tetapi menunda pencabutan. Tentukan berdasarkan frekuensi perubahan, risiko, dan perilaku browser, serta pertahankan jalur origin berversi (versioned-origin) atau TTL pendek untuk penarikan mendesak.
Pertanyaan lanjutan 3: Kapan origin wildcard dapat diterima?
Hanya untuk sumber daya yang benar-benar publik tanpa kredensial dan dengan penilaian risiko yang telah disetujui. Data akun, administrasi, dan tenant harus menggunakan origin eksplisit dan perilaku wildcard yang teruji.
Pertanyaan lanjutan 4: Bagaimana Anda mendeteksi origin yang diizinkan karena ketidaksengajaan?
Catat Origin, rute, hasil preflight, dan versi kebijakan; audit perubahan origin. Jalankan matriks otomatis dari origin yang diizinkan, tidak diizinkan, dan kedaluwarsa, serta blokir rilis jika header respons menyimpang dari kebijakan.