Cara Tes CORS API Sendiri dan Membaca Hasilnya

CORS atau Cross-Origin Resource Sharing sering dianggap ribet. Padahal, aturannya sederhana: browser memblokir permintaan lintas origin kecuali server tujuan mengizinkan lewat header tertentu. Banyak pengembang API menyalakan Access-Control-Allow-Origin: * untuk mengatasi error. Padahal, itu bisa membuka celah yang tidak perlu.

Menguji CORS sendiri bukan soal menjalankan satu perintah lalu selesai. Anda perlu memahami apa yang sebenarnya diizinkan, bagaimana membaca header respons, dan kapan konfigurasi menjadi indikasi risiko. Artikel ini memandu Anda menguji CORS API sendiri, baik lewat curl maupun dari browser, tanpa bergantung pada asumsi.

Sebagai pelengkap, AISG menyediakan pemindaian URL gratis di /#free-scan. Sensor berjalan lokal di mesin Anda, dan temuan yang muncul adalah indikasi yang perlu divalidasi manusia—bukan bukti eksploitasi.

Apa yang Sebenarnya Diizinkan CORS?

CORS tidak mencegah server menerima permintaan. Ia mengatur apakah browser boleh membaca respons dari domain berbeda. Jika server tidak mengirim header CORS, permintaan tetap sampai, tetapi browser memblokir hasilnya untuk JavaScript di halaman asal. Header kunci adalah Access-Control-Allow-Origin yang menentukan origin mana yang diizinkan.

Saat permintaan tidak sederhana, browser mengirim preflight dengan metode OPTIONS. Server harus merespons dengan header yang sesuai, misalnya Access-Control-Allow-Methods dan Access-Control-Allow-Headers. Preflight inilah yang sering salah dikonfigurasi.

Wildcard vs Daftar Origin: Perbedaan yang Sering Disalahpahami

Banyak orang menganggap * sama dengan "semua boleh". Secara teknis, * berarti setiap origin boleh membaca respons tanpa kredensial. Daftar origin eksplisit seperti https://app.saya.com hanya mengizinkan origin itu. Perbedaannya penting ketika Anda mengaktifkan kredensial.

Jika Anda mengirim cookie atau header Authorization, browser tidak akan menerima wildcard. Spesifikasi mensyaratkan server mencantumkan origin spesifik. Tetapi beberapa server tetap menggabungkan keduanya, dan ini berbahaya.

Bahaya Kombinasi Wildcard dan Kredensial

Mengapa berbahaya? Dengan kredensial, situs jahat bisa memanfaatkan sesi pengguna yang masih aktif di API Anda. Misalnya, pengguna login di api.anda.com, lalu membuka halaman evil.com. Jika API Anda merespons wildcard plus kredensial, evil.com berpotensi membaca data pribadi. Ini masih indikasi, bukan eksploitasi otomatis, tetapi sebaiknya dihindari.

Cara Tes CORS dengan curl

Mulailah dengan permintaan sederhana tanpa header kustom. Jalankan perintah berikut di terminal:

1. curl -I -H "Origin: https://example.com" https://api.anda.com/data
2. Periksa header respons. Jika ada Access-Control-Allow-Origin: https://example.com atau *, berarti origin itu diizinkan.
3. Uji dengan origin berbeda yang tidak sah: curl -I -H "Origin: https://evil.com" https://api.anda.com/data. Jika tetap mendapat * atau origin evil.com, konfigurasi Anda terlalu longgar.
4. Uji preflight dengan metode OPTIONS: curl -i -X OPTIONS -H "Origin: https://example.com" -H "Access-Control-Request-Method: PUT" https://api.anda.com/data. Perhatikan apakah header Access-Control-Allow-Methods memuat PUT.

Ganti URL dengan endpoint Anda. Hasil curl menunjukkan header yang dikirim server, bukan perilaku browser. Browser bisa lebih ketat, jadi uji juga dari sisi client.

Cara Tes CORS dari Browser

Buka DevTools di Chrome atau Firefox, pilih tab Network, lalu jalankan JavaScript dari halaman yang berbeda origin (bisa lewat konsol halaman lain atau ekstensi). Contoh kode untuk menguji:

fetch('https://api.anda.com/data', { credentials: 'include' }).then(r => r.json()).catch(e => console.error(e));

Jika muncul error CORS di konsol, baca pesannya. Biasanya menyebutkan header mana yang hilang atau tidak cocok. Anda juga bisa memakai mode disable web security untuk diagnosa, tetapi jangan jadikan itu solusi produksi.

Membaca Header Access-Control-* dengan Teliti

Jangan hanya melihat Access-Control-Allow-Origin. Ada beberapa header yang menentukan perilaku CORS:

• Access-Control-Allow-Origin: origin yang diizinkan atau *.
• Access-Control-Allow-Credentials: harus true jika Anda mengizinkan cookie/authorization lintas origin. Jangan gunakan dengan *.
• Access-Control-Allow-Methods: metode HTTP yang diizinkan untuk preflight.
• Access-Control-Allow-Headers: header kustom yang boleh dikirim client.
• Access-Control-Max-Age: berapa lama hasil preflight bisa di-cache.

Periksa konsistensi. Misalnya, jika Allow-Methods tidak memuat POST tetapi endpoint Anda menerima POST, browser akan memblokirnya setelah preflight.

Perbaikan yang Benar Tanpa Membuka Semuanya

Alih-alih menyalakan *, buat daftar origin yang valid. Jika API Anda hanya dipakai domain sendiri dan subdomain tertentu, cantumkan satu per satu. Untuk layanan publik yang tidak butuh kredensial, wildcard masih bisa diterima, tetapi tetap tinjau ulang.

Jangan lupa menangani preflight dengan benar. Pastikan server merespons OPTIONS dengan header yang sesuai dan tidak memerlukan autentikasi. Banyak framework modern punya middleware CORS; konfigurasikan origin whitelist, bukan refleksi asal-asalan.

Artikel terkait seperti CORS wildcard: kenapa berbahaya untuk API AI dan cara uji endpoint API tanpa login bisa membantu memperdalam konteks. Gunakan pemindaian AISG untuk indikasi awal, tetapi validasi manual tetap wajib.

Kesimpulan

Menguji CORS API sendiri bukan hanya menyalakan wildcard lalu selesai. Anda perlu memahami apa yang diizinkan, membaca header dengan cermat, dan menguji dari sisi curl maupun browser. Perbedaan antara wildcard dan daftar origin sangat menentukan, terutama ketika kredensial terlibat.

Dengan langkah-langkah di atas, Anda bisa menemukan konfigurasi yang longgar sebelum menjadi masalah. Ingat, temuan dari alat otomatis seperti AISG adalah indikasi, bukan bukti eksploitasi. Perbaiki dengan bijak: buka hanya origin yang benar-benar diperlukan.