Simulasikan preflight dan permintaan aktual dari sisi server, tentukan dengan cepat apakah masalahnya ada di Allow-Origin, Allow-Headers atau credentials.
Mensimulasikan preflight CORS dan permintaan sebenarnya secara nyata dari sisi server, memeriksa 6 header respons satu per satu, menentukan kesalahan konfigurasi cross-origin secara akurat, memberikan kode perbaikan untuk berbagai framework seperti Nginx/Node.js/Spring.
Ini adalah masalah CORS yang paling klasik! Karena Postman dan curl sama sekali tidak dibatasi oleh kebijakan same-origin browser — mereka adalah klien HTTP, bukan browser, tidak memblokir respons, juga tidak secara otomatis mengirim permintaan preflight OPTIONS. Error cross-origin adalah mekanisme keamanan yang unik bagi browser, hanya lingkungan runtime JavaScript browser yang akan menjalankan pemeriksaan CORS. Postman dapat dipanggil dengan sukses hanya membuktikan antarmuka itu sendiri dapat mengembalikan data, tidak dapat membuktikan konfigurasi CORS benar. Anda perlu menggunakan browser, atau alat ini (mensimulasikan alur CORS browser dari sisi server) untuk mendeteksi, baru akan menemukan masalah.
99% error CORS adalah masalah konfigurasi back-end (atau masalah konfigurasi lapisan Nginx/gateway), yang bisa dilakukan front-end sangat terbatas. Inti dari CORS adalah server«otorisasi»browser melalui header respons untuk mengizinkan akses cross-origin, front-end hanya dapat mengatur withCredentials, mengatur header permintaan ini, tidak dapat melewati batasan keamanan browser. Proxy front-end yang dikatakan di internet (devServer proxy, proxy terbalik Nginxproxy front-end dan antarmuka ke asal yang sama) pada dasarnya adalah«menipu»browser agar mengiraadalah permintaan same-origin, bukan benar-benar menyelesaikan masalah CORS, lingkungan produksi jika front-end dan back-end tidak sama-origin tetap perlu back-end mengonfigurasi CORS dengan benar.
Karena GET biasanya memenuhi kondisi permintaan sederhana, browserlangsung mengirim permintaan; sedangkan POST jika Anda mengirim Content-Type: application/json (90% antarmuka POSTsemua adalah ini),makatidaktermasuk permintaan sederhana lagi, akan memicu preflight OPTIONS. Permintaan preflight memerlukan server mengembalikan header CORS yang benar, banyak orang hanyamemberikan GET/POST mengonfigurasi header CORS tetapi tidak menangani metode OPTIONS, atau respons OPTIONS tidak membawa header,makamelaporkan errortelah. Metode seperti PUT/DELETE/PATCHsendirimakatidakadalah metode sederhana, pasti memicu preflight.
Lingkungan pengembanganada beberapajenisskema:①proxy bawaan framework (devServer.proxy milik Vue CLI, server.proxy milik Vite, proxy milik Create React App):proxy permintaan antarmuka ke asal yang sama dengan server pengembangan front-end, browser mengiraadalah permintaan same-origin tidak cross-origin;②menutup parameter keamanan browser (seperti Chrome menambahkan parametermengaktifkan --disable-web-security), hanya untuk pengujian sementara lokal, sama sekali tidak boleh digunakan untuk penjelajahan normal;③back-end mengonfigurasi CORS mengizinkan asal localhost (disarankan, perilakunya konsisten dengan lingkungan produksi). Lingkungan produksi harus back-end mengonfigurasi CORS dengan benar: konfigurasikan daftar putih asal yang diizinkan, atur Allow-Methods/Allow-Headers/Allow-Credentials dengan benar, tambahkan Vary: Origin, atau gunakan gateway/Nginx untuk menangani CORS secara terpadu.
Tidak bisa, header respons Access-Control-Allow-Origin hanya boleh memiliki satu nilai, baik itu satu asal spesifik (seperti https://a.com), atau *. Browser tidak menerima beberapa asal (misalnya menulis https://a.com,https://b.com tidak valid, browser akan menganggap tidak cocok). Cara konfigurasi multi-asal yang benar adalah: server memelihara daftar putih asal yang diizinkan, setiap kali menerima permintaan baca nilai Origin di header permintaan, periksa apakah Origin ini ada dalam daftar putih, jika ada maka atur Access-Control-Allow-Origin menjadi nilai Origin spesifik ini,sekaligusmengembalikan header Vary: Origin; jika tidak ada maka tidak mengembalikan header CORS atau mengembalikan error. Jangan mencoba mengembalikan beberapa header Allow-Origin atau menggunakan koma untuk memisahkan beberapa nilai, browsersemua tidak mengenali.
Permintaan preflight OPTIONStidak perlu mengembalikan logika bisnis dan badan respons apa pun, hanya perlu mengembalikan header respons CORS yang benar dan kode status 200/204makabisatelah. Browser menerima header CORS yang benarmaka menganggap preflight lulus, tidak akan membaca konten body respons OPTIONS. Jadi praktik terbaik adalah: langsung intersep permintaan OPTIONS di lapisan Nginx/gateway, kembalikan 204 No Content dan header CORS yang benar, tidak diteruskan ke server aplikasi back-end,seperti inisekaligus mengurangi beban back-end, juga menghindari kesalahan 405 yang disebabkan oleh rute back-end tidak mendukung OPTIONS. Tetapi perhatikan untuk memastikan header CORS respons OPTIONS dan header CORS permintaan sebenarnya tetap konsisten.
Permintaan cross-origin yang membawa Cookie perlu sekaligus memenuhi tiga kondisi:①front-end XMLHttpRequest.withCredentials = true atau credentials fetch: 'include';②header respons back-end Access-Control-Allow-Credentials: true;③Access-Control-Allow-Origin tidak boleh *, harus berupa asal spesifik. Ketiga kondisikurang satu tidak bisa. Selain itu juga perlu memperhatikan atribut Cookie: Cookie harus disetel SameSite=None; Secure (lingkungan HTTPS)baru bisa dibawa dalam permintaan cross-origin; jika Cookieadalah SameSite=Lax atau Strict, permintaan cross-origin tidak akan membawa; atribut Domain Cookie harus diatur dengan benar; juga perlu memperhatikan dampak kebijakan Cookie pihak ketiga (browser seperti Chrome memiliki batasan terhadap Cookie pihak ketiga).
CORS adalah melonggarkan batasan akses cross-origin, CSRF adalah serangan pemalsuan permintaan lintas situs, keduanyaadalah konsep yang berbeda. Mengonfigurasi CORS dengan benar tidak akan langsungmenyebabkan kerentanan CSRF — karena CORS hanya mengizinkan JS membaca respons, sedangkan CSRF adalah penyerang memicu pengguna mengirimkan permintaan tanpa sepengetahuan (seperti tag img, formulir pengiriman otomatis), permintaan ini meskipun tidak ada CORS juga akan terkirim membawa Cookie. Pertahanan CSRF perlu menggunakan skema seperti CSRF Token, SameSite Cookie, verifikasi Origin/Referer, tidak dapat mengandalkan menonaktifkan CORS untuk mencegah CSRF. Tetapi jika Anda mengonfigurasi CORSsaat menyetel Allow-Origin menjadi * dan mengizinkan membawa credentials, memang akan memperbesar risiko CSRF, jadi skenario membawa credentialah mutlak tidak bisa menggunakan *, harusketat membatasi asal daftar putih.
Tag <img>, <script>, <link> biasa memuat sumber daya cross-origin (gambar CDN, skrip JS, CSS) secara default tidak ada masalah CORS, iniadalah«sumber daya tertanam»bukan«permintaan AJAX», browser mengizinkan pemuatan tetapi JS tidak dapat membaca konten. Tetapi jika Anda ingin memanipulasi gambar cross-origin di Canvas, atau menggunakan fetch/XHR untuk memuat sumber daya ini dan membaca konten,maka perlu CORS,sekaliguspada tagperlu menambahkan atribut crossorigin. Unduh file cross-origin (klik unduh tag a) secara default juga tidak perlu CORS. Pengalihan akan memengaruhi CORS: jika permintaan preflight OPTIONS mengembalikan pengalihan 3xx, browser akan langsung menolak (Preflight redirect is not allowed); pengalihan permintaan sebenarnya jikaadalah lintas asal, setiap hop perlu mengembalikan header CORS dengan benar.
Poin konfigurasi yang disarankan Nginx:①gunakan instruksi map untuk mencocokkan daftar putih Origin, atur variabel $cors_origin secara dinamis;②permintaan OPTIONS langsung mengembalikan 204 tidak meneruskan ke back-end;③add_header ingat tambahkan parameter always untuk memastikan respons error juga membawa header;④tambahkan Vary: Origin;⑤konfigurasikan Allow-Methods/Allow-Headers/Credentials dengan benar. Contoh konfigurasi dapat ditemukan dalam saran perbaikan hasil deteksi alat ini, untuk frameworkbrowser modern seperti Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin kami semua menyediakan potongan konfigurasi yang telah terverifikasi.
Beberapa langkah untuk memverifikasi CORS:①pertama gunakan alat ini untuk deteksi online, masukkan URL, Origin, metode, header, opsi credentials, lihat apakah berbagai pemeriksaan preflight dan permintaan sebenarnya lulus;②buka panel Network DevTools browser, centang Disable cache menonaktifkan cache (menghindari gangguan cache lama), picu permintaan cross-origin, periksa apakah header respons preflight OPTIONS dan permintaan sebenarnya benar;③di Console lihat apakah ada error terkait CORS;④uji skenario berbeda: permintaan GET tanpa header kustom, permintaan POST dengan application/json, metode PUT/DELETE, membawa/tidak membawa Cookie, membawa header kustom;⑤gunakan curl untuk mensimulasikan permintaan OPTIONS: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, periksa apakah header respons benar.
Browser yang berbeda memiliki perbedaan detail implementasi terhadap spesifikasi CORS:①Safari memiliki batasan yang lebih ketat terhadap Max-Age cache preflight (versi awal hanya 600 detik), kebijakan Cookie (ITP anti-pelacakan cerdas) juga lebih ketat, mungkin menyebabkan masalah Cookie cross-origin;②Chrome memiliki pemeriksaan wildcard yang lebih ketat saat membawa credentials, Allow-Headers/Allow-Methods juga tidak mengizinkan *, Firefox beberapa versi mungkin lebih longgar;③IE versi lama (IE11) menggunakan XDomainRequest bukan XMLHttpRequest standar, implementasi CORSada banyak jebakan (seperti tidak mendukung header kustom, hanya mendukung GET/POST);④browser yang berbeda memiliki perbedaan halus dalam penanganan header Vary, penanganan pengalihan, penanganan header keamanan. Solusinya adalahketat mengonfigurasi sesuai spesifikasi CORS, jangan mengandalkan perilaku kompatibilitas satu browser.
Disarankan untuk mengatur antara 3600 (1 jam) hingga 86400 (24 jam). Diatur terlalu pendek (seperti 60 detik): cache preflight cepat kedaluwarsa, sering mengirimkan permintaan OPTIONS, meningkatkan waktu konsumsi permintaan dan tekanan server, dampaknya terlihat jelas di lingkungan jaringan lemah seluler. Diatur terlalu lama (seperti 31536000yaitu satu tahun): jika Anda memperbarui konfigurasi CORS (seperti menambahkan metode, header yang diizinkan), hasil preflight lama yang di-cache browser pengguna mungkin membutuhkan waktu lamabaru kedaluwarsa, selama itu akanmuncul masalah konfigurasi tidak berlaku. Selain itu Chrome dan Firefox akan secara otomatis memotong nilai yang melebihi 86400 detik menjadi 86400 detik, Anda mengatur sepanjang apa pun tidak berguna. Lingkungan pengembangan dapat diatur -1 untuk menonaktifkan cache preflight, memudahkan debug.
WebSocket (ws:// dan wss://) tidak dibatasi oleh mekanisme HTTP CORS, karena WebSocketadalah protokol independen, bukan permintaan HTTP AJAX. Tetapi tahap jabat tangan WebSocket adalah permintaan HTTP, server dapat memeriksa header Origin untuk memutuskan apakah mengizinkan koneksi — ini adalah kontrol izin pada tingkat WebSocket, bukan CORS standar, tetapi prinsipnya mirip. Jika koneksi WebSocket ditolak, Anda perlu memeriksa konfigurasi verifikasi Origin sisi server WebSocket, bukan header HTTP CORS. Pustaka seperti Socket.IO mungkinada cara konfigurasi cross-origin sendiri, mirip dengan konfigurasi CORS standar tetapi tidak sepenuhnya sama. Selain itu, API browserlainnya seperti HTTP/2 Server Push, WebRTC juga ada kontrol izinmasing-masing, tidak sepenuhnya mengikuti HTTP CORS.
Alat ini secara ketat mensimulasikan alur preflight dan permintaan sebenarnya browser sesuai spesifikasi W3C CORS di sisi server, logika pemeriksaan terhadap header CORSpada dasarnya konsisten dengan browser modern. Jika alat mendeteksi lulus tetapi browser tetapmelaporkan error, kemungkinan penyebabnya:①browser menyimpan cache hasil preflight atau respons lama, tekan Ctrl+F5 refresh paksa atau bersihkan cache lalu coba lagi;②ekstensi browser (pemblokir iklan, perlindungan privasi, plugin keamanan) memodifikasi atau memblokir permintaan;③Origin, header permintaan, metode, opsi credentials yang Anda isi di alat tidak konsisten dengan yang sebenarnya dikirim front-end (misalnya front-end sebenarnyamasih membawa header kustom tertentu tetapi Anda tidak menambahkannya di alat);④cache node CDN/proxy tidak konsisten, node yang diminta alat dan node yang diminta browser mengembalikan hasil berbeda;⑤browserada kebijakan keamanan khusus (seperti halaman HTTPS meminta HTTP konten campuran diblokir, batasan khusus protokol file:// file lokal).
