CORS: Memahami Cross-Origin Resource Sharing dan Cara Mengamankannya

Daftar Isi

• Pendahuluan
• Apa yang Sebenarnya Dikontrol CORS?
• Origin vs Site
• Simple Request dan Preflight
• Credentials dan Cookies
• Konfigurasi Aman yang Umum Dipakai
• Kesalahan Umum
• Checklist
• FAQ
• Kesimpulan

Pendahuluan

CORS adalah topik keamanan browser yang sering dikenal developer lewat error message. Frontend memanggil API, browser memblokir response, lalu semua orang mulai mengubah header sampai request berhasil.

Pendekatan seperti itu berisiko. CORS bukan gangguan browser acak. CORS mengontrol origin mana yang boleh membaca response dari API kamu dalam konteks browser.

Untuk mengatur CORS dengan aman, kamu perlu memahami origin, preflight request, credentials, dan kenapa * tidak selalu boleh dipakai.

Apa yang Sebenarnya Dikontrol CORS?

CORS adalah singkatan dari Cross-Origin Resource Sharing.

CORS memberi tahu browser apakah JavaScript yang berjalan di satu origin boleh membaca response dari origin lain.

Contoh:

Frontend origin	API origin	Cross-origin?
https://app.example.com	https://api.example.com	ya
https://app.example.com	https://app.example.com	tidak
http://localhost:3000	http://localhost:8080	ya

CORS ditegakkan oleh browser. CORS bukan pengganti authentication, authorization, CSRF protection, atau validasi server-side.

Origin vs Site

Origin terdiri dari scheme, host, dan port.

https://app.example.com:443

Jika salah satu bagian berbeda, origin-nya berbeda.

URL A	URL B	Same origin?
https://app.example.com	https://app.example.com	ya
https://app.example.com	https://api.example.com	tidak
http://app.example.com	https://app.example.com	tidak
http://localhost:3000	http://localhost:5173	tidak

Ini alasan local development sering memunculkan masalah CORS.

Simple Request dan Preflight

Sebagian request browser termasuk simple request. Sebagian lain membutuhkan preflight.

Preflight adalah request OPTIONS yang dikirim browser sebelum request asli. Browser bertanya ke server apakah request sebenarnya boleh dikirim.

Contoh preflight:

OPTIONS /api/orders HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

Contoh response:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: authorization, content-type

Jika preflight gagal, browser tidak akan mengirim request asli.

Credentials dan Cookies

Credentials mengubah aturan. Jika request menyertakan cookies atau HTTP auth, server harus mengizinkan credentials secara eksplisit.

Access-Control-Allow-Credentials: true

Saat credentials diizinkan, konfigurasi ini tidak valid:

Access-Control-Allow-Origin: *

Server harus mengembalikan origin spesifik yang memang diizinkan.

Skenario	Header origin yang aman
public read-only API	* bisa diterima
cookie-based app API	exact trusted origin
multi-tenant dashboard	validated tenant origin

Konfigurasi Aman yang Umum Dipakai

Setup CORS yang lebih aman biasanya seperti ini:

• simpan allowlist origin tepercaya
• return exact origin hanya jika ada di allowlist
• allow method yang memang dibutuhkan
• allow header yang memang dibutuhkan
• enable credentials hanya jika diperlukan
• pisahkan CORS dari authentication

Contoh policy:

Setting	Contoh
allowed origins	https://app.example.com
methods	GET, POST, PATCH, DELETE
headers	authorization, content-type
credentials	hanya jika memakai cookies

Kesalahan Umum

Memakai * untuk private API

Untuk private API, origin policy yang terlalu terbuka bisa mengekspos response ke browser context yang tidak dipercaya.

Me-reflect origin apa pun

Sebagian server mengembalikan origin apa pun yang dikirim di header Origin. Ini pada praktiknya sama seperti allow-all.

Mengira CORS sama dengan auth

CORS mengontrol akses browser terhadap response. API tetap butuh authentication dan authorization.

Melupakan preflight

Custom header, JSON POST, dan authorization header sering memicu preflight. API perlu menangani OPTIONS dengan benar.

Mengizinkan credentials tanpa hati-hati

Credentialed request butuh origin check yang lebih ketat karena cookies bisa dikirim otomatis.

Checklist

• Definisikan origin yang boleh mengakses API.
• Hindari * untuk private API atau credentialed API.
• Jangan reflect arbitrary origin.
• Allow hanya method yang dibutuhkan.
• Allow hanya header yang dibutuhkan.
• Tangani preflight OPTIONS dengan benar.
• Enable credentials hanya saat perlu.
• Tetap jalankan auth dan authorization di server.
• Test origin local, staging, dan production secara terpisah.
• Log rejected origin saat rollout.

FAQ

Apakah CORS melindungi API dari non-browser client?

Tidak. CORS ditegakkan oleh browser. Server, script, curl, dan mobile app tidak diblokir oleh CORS.

Kenapa Postman berhasil tapi browser gagal?

Postman bukan browser dan tidak menerapkan CORS. Browser memblokir akses response cross-origin berdasarkan header CORS.

Apakah CORS bisa dimatikan?

Kamu bisa melonggarkan CORS, tapi jangan asal mematikannya untuk private API. Gunakan allowlist yang presisi.

Kesimpulan

CORS adalah boundary keamanan browser, bukan sekadar hambatan deployment. Ia menentukan origin mana yang boleh membaca response API dari JavaScript di browser.

Gunakan allowlist origin yang spesifik, tangani preflight dengan benar, hati-hati dengan credentials, dan ingat bahwa CORS melengkapi authentication, bukan menggantikannya.