CORS wildcard: kenapa berbahaya untuk API aplikasi AI

Access-Control-Allow-Origin: * adalah header yang paling sering ditambahkan untuk "supaya tidak kena error CORS". Masalahnya: header itu bukan perbaikan, ia memberi tahu browser bahwa situs mana pun di internet boleh membaca respons dari API Anda. Untuk halaman statis tanpa data, itu wajar. Untuk API yang memakai sesi pengguna atau memegang kuota berbayar, itu pintu terbuka.

Apa yang sebenarnya diatur CORS

CORS adalah aturan browser, bukan firewall. Tanpa izin dari server, JavaScript di situs-lain.com tidak bisa membaca respons API Anda — server tetap menerima permintaan, tapi hasilnya tidak bisa dibaca oleh skrip penyerang. Ketika server mengirim *, izin itu diberikan ke semua orang, tanpa perlu tahu siapa yang meminta.

Kombinasi yang paling berbahaya adalah Access-Control-Allow-Origin: * bersama Access-Control-Allow-Credentials: true. Browser modern menolak kombinasi ini, tetapi banyak server tetap mengirimnya, dan sebagian implementasi kustom menggemakan Origin apa pun yang masuk — efeknya sama: siapa pun boleh membaca respons yang memakai kredensial.

Kenapa aplikasi AI sering kena

• Front-end memanggil API dari browser. Karena kunci API sudah ada di klien (lihat artikel API key bocor di aplikasi vibe coding), panggilan lintas domain jadi hal biasa — dan wildcard dipakai sebagai jalan pintas.
• Backend tanpa allowlist. Template server yang menyalin header Origin dari request akan "mengizinkan" domain penyerang tanpa sadar.
• Endpoint pengembangan ikut ke produksi. Server dev yang membuka semua origin sering ter-deploy apa adanya.

Kapan wildcard itu benar-benar berbahaya

Jawabannya bergantung pada satu hal: apakah respons memuat data yang tidak boleh dibaca orang lain.

• Tidak berbahaya — endpoint publik tanpa sesi, misalnya daftar harga atau status layanan. Wildcard di sini hanya soal kenyamanan.
• Berbahaya — endpoint yang memakai cookie sesi, memuat data pengguna, memotong kuota (token LLM berbayar), atau menerima perintah yang mengubah data. Di sini wildcard = siapa pun bisa memicu biaya atau membaca data atas nama pengguna Anda.

Cara memeriksa dengan satu perintah

Kirim permintaan dengan Origin palsu dan lihat jawaban server:

curl -sI -H "Origin: https://evil.example" https://api.domain-anda.com/v1/chat | grep -i "access-control"

• Access-Control-Allow-Origin: * → semua origin diizinkan.
• Access-Control-Allow-Origin: https://evil.example → server menggemakan origin apa pun; ini sama longgarnya, tapi lebih menipu karena terlihat "spesifik".
• Access-Control-Allow-Origin: https://app.domain-anda.com → benar: hanya origin yang Anda daftarkan.
• Tidak ada header CORS sama sekali → browser memblokir pembacaan lintas origin; ini aman untuk API.

Perhatikan juga Vary: Origin. Server yang menggemakan origin tanpa Vary bisa membuat cache menyajikan izin milik domain lain kepada pengunjung berikutnya.

Perbaikan yang benar (bukan menambah wildcard)

1. Allowlist eksplisit. Simpan daftar origin yang sah di konfigurasi server, bandingkan persis (bukan startsWith atau includes), lalu kembalikan origin itu saja.
2. Jangan gabungkan * dengan credentials. Kalau butuh sesi, allowlist adalah satu-satunya pilihan.
3. Pindahkan panggilan LLM ke server Anda. Browser berbicara ke backend Anda; backend yang memegang kunci dan kuota.
4. Uji ulang setelah deploy dengan perintah curl di atas — jangan berasumsi konfigurasi baru sudah aktif.

Bagaimana AISG melaporkannya

Pada free URL scan, kondisi ini muncul sebagai temuan medium dengan rule FS-030 (CWE-942), berisi bukti berupa nilai header yang terlihat dan status credentials. Sifatnya indikasi: AISG tidak menguji apakah data Anda benar-benar bisa dicuri, karena itu bagian yang harus Anda putuskan sendiri dengan melihat endpoint mana yang memakai sesi. Satu hal yang sering disalahpahami: wildcard pada halaman landing statis tidak otomatis menjadi kebocoran — yang menentukan adalah apa yang dikirim endpoint itu.