Generator CORS
Izin lintas asal tanpa membuka API ke seluruh internet
Susun header CORS untuk Nginx, Apache, atau PHP dengan daftar asal yang dicocokkan, penanganan preflight, dan Vary yang benar. Menolak gabungan pengaturan yang membuka API ke siapa saja.
Pasang di server yang MELAYANI API, bukan di situs yang memanggilnya. Ini kekeliruan arah yang paling sering terjadi.
Seluruh perhitungan berjalan di browser Anda. Alamat IP, nama interface, dan password yang Anda masukkan tidak pernah dikirim ke server CoreNet.
Arah yang sering keliru
CORS dipasang di server yang melayani API, bukan di situs yang memanggilnya. Ia adalah izin yang diberikan penyedia data kepada pemanggilnya. Memasangnya di sisi pemanggil tidak berpengaruh apa pun — dan itu jam-jam pertama yang paling sering terbuang saat menghadapi error CORS.
CORS bukan pengaman API
Ini perlu dinyatakan sejelas mungkin: CORS hanya mengatur apa yang boleh dilakukan JavaScript di browser orang lain. curl, Postman, dan program apa pun mengabaikannya sepenuhnya — mereka tidak pernah bertanya izin.
Karena itu API yang perlu dilindungi tetap membutuhkan autentikasi. Mengandalkan CORS sebagai pembatas akses adalah salah paham yang tampak berhasil sampai seseorang membuka Postman.
Gabungan yang ditolak tool ini
Access-Control-Allow-Origin: * tidak boleh digabung dengan Allow-Credentials: true. Browser memang menolaknya — tetapi yang berbahaya bukan penolakannya, melainkan cara orang mengatasinya: memantulkan kembali apa pun isi header Origin.
Itu berarti setiap situs di internet menjadi asal yang diizinkan, lengkap dengan cookie session pengguna. Siapa pun dapat membuat halaman yang membaca data akun pengunjung Anda hanya dengan menunggu mereka membukanya.
Tool ini menolak menghasilkan pola itu.
Vary: Origin, dan kenapa ia wajib
Ketika beberapa asal diizinkan, server harus mencocokkan Origin yang masuk lalu memantulkan yang cocok. Tanpa header Vary: Origin, cache di depan server dapat menyimpan jawaban untuk satu asal lalu menyajikannya ke asal lain.
Gejalanya khas dan menyiksa: penolakan CORS yang datang dan pergi tanpa pola yang jelas, hanya pada sebagian pengunjung, dan hilang saat Anda memeriksanya sendiri.
Preflight
Untuk permintaan selain GET dan POST sederhana, browser mengirim OPTIONS lebih dulu untuk bertanya izin. Konfigurasi yang dihasilkan menjawabnya langsung tanpa menyentuh aplikasi — lebih cepat, dan menghindari framework yang menolak metode OPTIONS.
Access-Control-Max-Age menyimpan jawaban itu, sehingga preflight tidak diulang untuk setiap permintaan.
Bila memakai cookie
Dua hal yang harus benar bersamaan, dan salah satunya sering terlewat:
- Sisi client:
fetch(url, { credentials: "include" }) - Cookie session-nya:
SameSite=None; Secure
Tanpa yang pertama, header server tidak ada gunanya. Tanpa yang kedua, browser modern membuang cookie-nya diam-diam. Gejalanya sama pada keduanya: permintaan berhasil tetapi selalu dianggap belum masuk.
Pertanyaan yang sering diajukan
Kenapa error CORS muncul padahal header sudah dipasang? Periksa apakah Origin yang dikirim benar-benar sama persis dengan yang ada di daftar — termasuk https:// dan tanpa garis miring di ujung. Browser membandingkannya persis.
Boleh memakai wildcard subdomain? Standar CORS tidak mengenalnya. Yang harus dilakukan adalah mencocokkan sendiri di server lalu memantulkan asal yang cocok.
Apa yang terjadi bila server tidak mengirim header CORS sama sekali? Browser memblokir jawabannya. Permintaannya sendiri tetap sampai ke server dan tetap diproses — jadi permintaan yang mengubah data tetap terjadi walau jawabannya diblokir.