Kenalin, Saya CORS, Saya Satpam Domain

Pernah nggak, lagi asik-asiknya ngoding buat web, tiba-tiba ketemu error ngeselin soal CORS? Buat yang belum tahu, Cross-Origin Resource Sharing (alias CORS) itu kayak satpamnya browser yang tugasnya ngecek, “Eh, domain ini boleh nggak ya ngambil data dari domain lain?” Nah, biar nggak bingung, yuk kita bahas CORS dengan bahasa yang santai dan gampang dipahami.

Apa Itu CORS?

Jadi, CORS (Cross-Origin Resource Sharing) itu semacam sistem keamanan yang ada di browser. Fungsinya? Biar website di satu domain bisa (atau nggak bisa) minta resource dari domain lain. Contohnya, kamu punya website di domain-A.com yang butuh data dari domain-B.com. Nah, kalau nggak ada CORS, semua website bisa asal comot data dari mana-mana, dan itu bisa bahaya, bro!

Intinya, CORS ini kayak aturan yang nentuin: “Oke, website ini boleh ngakses data gue,” atau sebaliknya, “Nope, nggak boleh.”

Cara Kerja CORS

CORS kerja lewat header HTTP yang dipasang di server. Header-header ini kayak semacam ‘stempel izin’ yang dikasih ke browser biar dia tahu, “Wah, domain ini aman buat dimintain data.” Biar makin paham, berikut beberapa header penting yang sering dipakai:

• Access-Control-Allow-Origin: Ini yang paling penting. Header ini ngasih tahu domain mana aja yang boleh ngakses resource di server.
• Access-Control-Allow-Credentials: Kalau header ini ada, berarti resource boleh diakses dengan info login (kayak cookie atau session).
• Access-Control-Allow-Headers: Header ini nyebutin header-header custom apa aja yang boleh dipake pas ngirim request.
• Access-Control-Allow-Methods: Ngasih tahu method HTTP apa aja (GET, POST, PUT, dll.) yang boleh dipake.
• Access-Control-Expose-Headers: Ngasih tahu header mana aja yang aman buat ditampilin ke browser.
• Access-Control-Request-Headers: Header ini muncul di request preflight dan ngasih tahu server header-header apa yang bakal dipake.
• Access-Control-Request-Method: Ini buat request preflight juga, buat ngasih tahu server method HTTP apa yang bakal dipake.

Gimana Sih Alur Kerja CORS?

CORS itu bisa dibagi jadi dua jenis request: Simple Request dan Preflight Request.

1. Simple Request:
   • Ini jenis request yang nggak ribet, nggak perlu cek-cok preflight segala.
   • Biasanya cuma make header-header standar.
   • Contohnya: GET, POST, atau HEAD.

   Contoh alurnya:

   • Client di domain-A.com nge-request data pake metode GET ke domain-B.com.
   • Server di domain-B.com respon dengan data, plus header Access-Control-Allow-Origin: domain-A.com.
   • Browser ngecek header ini, kalau domainnya cocok, data dikasih ke halaman web. Kalau nggak, ya bye-bye datanya.
2. Preflight Request:
   • Nah, yang ini kayak pengecekan sebelum request utama. Browser ngirim request OPTIONS dulu ke server buat mastiin aman nggak nih buat dilanjutin.
   • Biasanya dipake buat request yang nggak standar atau pake method yang ‘serius’, kayak PUT atau DELETE.

   Contoh alurnya:

   • Client di domain-A.com mau ngirim data pake metode PUT ke domain-B.com. Tapi sebelum itu, dia kirim request OPTIONS dulu.
   • Server respon dengan header Access-Control-Allow-Methods: PUT dan Access-Control-Allow-Headers: Content-Type.
   • Kalau jawaban server oke, client lanjut kirim PUT request aslinya.
   • Server kasih respon dengan header Access-Control-Allow-Origin: domain-A.com, dan browser ngecek ulang header ini. Kalau cocok, proses dilanjutin, kalau nggak, stop di situ.

Dengan setup CORS yang tepat, website kamu bisa aman dan tetap bisa ngambil resource dari domain lain dengan lancar. Jadi, walaupun kadang bikin pusing, CORS ini penting banget buat keamanan web kamu.

Analogi 

Misalnya kamu lagi bikin pesta di rumah kamu sendiri, sebut aja Rumah A. Terus ada temen kamu, Rumah B, yang pengen pinjam makanan dari pesta kamu buat dibagi ke tamu-tamu di sana. Nah, biar aman, kamu punya satpam di depan pintu (browser) yang tugasnya ngecek siapa aja yang boleh masuk dan ambil makanan.

1. Access-Control-Allow-Origin itu kayak daftar tamu VIP di pintu. Kalau nama Rumah B ada di daftar, satpam bakal ngizinin dia ambil makanan. Kalau nggak ada? Ya, maaf-maaf, silakan minggir.
2. Access-Control-Allow-Methods itu kayak aturan pesta kamu yang bilang, “Oke, tamu boleh ambil makanan sendiri (GET), boleh minta makanan diantar (POST), tapi nggak boleh bawa pulang satu nampan utuh (misalnya DELETE).”
3. Preflight Request itu kayak satpam yang mastiin ke kamu dulu, “Eh, Rumah B ini beneran aman buat ambil makanan gak sih?” sebelum ngasih akses buat ambil makanan langsung. Jadi, satpam kirim pesan ke kamu dulu (request OPTIONS), dan kamu jawab, “Oke, si Rumah B boleh ambil dengan aturan ini dan itu.”

Contoh Kasus Nyata

Kamu bikin aplikasi web di domain-A.com dan aplikasi itu butuh data cuaca dari API yang ada di api-cuaca.com.

• Simple Request: Kalau aplikasi kamu cuma ambil data cuaca pakai GET, dan api-cuaca.com udah nge-set header Access-Control-Allow-Origin: domain-A.com, data bisa langsung diakses tanpa drama.
• Preflight Request: Tapi kalau kamu mau ngirim data ke api-cuaca.com pake POST atau PUT (misalnya buat update data atau request khusus), browser bakal kirim preflight request OPTIONS dulu buat ngecek apakah api-cuaca.com ngasih izin metode dan header yang mau kamu pake.

Dengan analogi ini, kebayang kan gimana CORS kerja dan kenapa penting buat keamanan? Pesta di rumah kamu jadi aman dan teratur, dan cuma tamu yang diizinkan aja yang bisa nikmatin makanan. Browser juga aman, karena nggak asal kasih akses ke semua tamu yang datang.

Kapan Harus Menggunakan CORS?

1. Saat Mengakses API Eksternal: Kalau web kamu di domain-A.com perlu ambil data dari domain-B.com (misalnya dari layanan API publik seperti data cuaca, berita, dll.), kamu harus memastikan bahwa server di domain-B.com sudah mengizinkan permintaan dari domain kamu dengan header CORS yang sesuai. Kalau nggak, browser bakal blokir permintaan itu demi alasan keamanan.
2. Aplikasi dengan Frontend dan Backend di Domain Berbeda: Kalau kamu bikin aplikasi web di mana frontend dan backend dipisah di domain/subdomain yang berbeda, misalnya frontend di app.mysite.com dan backend API di api.mysite.com, kamu perlu konfigurasi CORS di server backend biar frontend bisa akses datanya.
3. Situs yang Menggunakan Resource dari Domain Lain: Misalnya, kamu punya situs yang perlu akses resource (seperti file CSS, font, atau gambar) dari domain lain. Kalau resource ini diambil dengan cara tertentu yang bikin browser menganggapnya cross-origin, server sumber resource itu perlu di-set agar mengizinkan akses tersebut lewat header CORS.

Kapan Tidak Perlu Menggunakan CORS?

1. Request Internal dalam Domain yang Sama: Kalau frontend dan backend kamu ada di domain yang sama, misalnya frontend di www.mysite.com dan backend di api.mysite.com/api, biasanya nggak perlu setting CORS karena ini dianggap same-origin dan browser nggak akan memblokir permintaannya.
2. Akses Resource Statis di Server yang Sama: Kalau kamu hanya mengakses resource statis seperti gambar, skrip, atau stylesheet yang disimpan di server yang sama, kamu nggak butuh CORS. Browser secara otomatis ngizinin akses dari domain yang sama.
3. Untuk Aplikasi Backend yang Tidak Diakses Langsung oleh Browser: Kalau aplikasi backend kamu hanya digunakan untuk berkomunikasi dengan server lain dan bukan browser langsung (misalnya untuk server-to-server API), kamu nggak butuh CORS karena mekanisme keamanan CORS cuma dipakai oleh browser. Jadi, permintaan dari backend ke backend aman-aman aja tanpa aturan CORS.
4. Skenario Lokal Development Tanpa Cross-Domain: Kalau kamu ngedevelop dan semuanya ada di lingkungan lokal (localhost), kamu bisa set environment supaya cross-origin issue nggak muncul. Tapi, ingat, ini solusi sementara dan nggak boleh dijadiin standar di produksi.

Kamu harus hati-hati saat setting CORS, terutama dengan header Access-Control-Allow-Origin: * yang bisa mengizinkan semua domain akses resource kamu. Ini bisa jadi celah keamanan kalau nggak dikontrol dengan baik. Jadi, pastikan hanya domain yang benar-benar perlu aja yang dikasih izin.

Nempelin Dimana ?

CORS biasanya diimplementasikan di web server dan diatur dalam konfigurasi server yang melayani resource yang diminta. Ini dilakukan untuk mengontrol permintaan cross-origin yang diizinkan atau ditolak. Berikut penjelasan di mana dan bagaimana CORS diterapkan:

1. Web Server:

• Apache: Kamu bisa mengatur CORS di file .htaccess atau di konfigurasi server utama dengan menambahkan direktif seperti Header set Access-Control-Allow-Origin "*" atau dengan lebih spesifik untuk domain tertentu.
• Nginx: Kamu bisa mengatur header CORS di file konfigurasi Nginx dengan perintah add_header 'Access-Control-Allow-Origin' 'https://domain.com';.
• IIS (Internet Information Services): Untuk server berbasis Windows, CORS bisa diatur melalui konfigurasi di web.config.

2. Bahasa Pemrograman (Aplikasi Backend):

Kalau kamu punya aplikasi backend atau API, CORS bisa diatur lewat kode program. Ini memungkinkan kontrol yang lebih fleksibel, seperti menentukan izin CORS hanya untuk rute tertentu atau berdasarkan kondisi spesifik.

• Node.js/Express: Ada middleware seperti cors yang bisa diinstall dan digunakan dengan cepat. Contoh:
  javascript

  const cors = require('cors');
  app.use(cors({
    origin: 'https://domain.com'
  }));

   

• Python/Flask: Kamu bisa menggunakan library flask-cors untuk mengatur CORS di Flask.
  python

  from flask import Flask
  from flask_cors import CORS
  
  app = Flask(__name__)
  CORS(app, resources={r"/api/*": {"origins": "https://domain.com"}})

   

• Java (Spring Boot): Kamu bisa mengatur CORS dengan menambahkan anotasi di controller atau konfigurasi global di WebMvcConfigurer.
  java

  @Configuration
  public class WebConfig implements WebMvcConfigurer {
      @Override
      public void addCorsMappings(CorsRegistry registry) {
          registry.addMapping("/**").allowedOrigins("https://domain.com");
      }
  }

   

3. Framework dan Platform:

Beberapa framework frontend seperti React, Angular, dan Vue.js tidak bisa mengatur CORS di browser secara langsung karena mereka berjalan di sisi klien. Namun, permintaan dari aplikasi ini harus diarahkan ke server backend yang sudah dikonfigurasi dengan izin CORS yang tepat.

4. Proxy dan API Gateway:

Kadang, CORS juga diatur di proxy server atau API gateway seperti NGINX Proxy, HAProxy, atau platform cloud seperti AWS API Gateway. Ini berguna untuk mengontrol CORS di satu titik sentral sebelum permintaan diteruskan ke server backend.

Tempat Tepat untuk Mengimplementasikan CORS

• Web Server: Ideal untuk kontrol statis dan global, seperti pengaturan yang berlaku untuk semua permintaan ke domain.
• Backend Aplikasi: Berguna jika kamu butuh kontrol dinamis, seperti mengatur izin berdasarkan logika bisnis atau aturan keamanan tertentu.
• Proxy/API Gateway: Praktis untuk skenario di mana kamu punya banyak microservices atau titik API berbeda yang dikelola dari satu tempat.

Jadi, CORS diimplementasikan terutama di server yang melayani resource (web server atau backend aplikasi), bukan di frontend. Browser hanya memverifikasi dan menegakkan aturan CORS; pengaturannya dilakukan di sisi server. Detailnya bisa ke sini