Cara Mengatasi Error CORS di Semua Server (Lengkap)

Error CORS (Cross-Origin Resource Sharing) itu salah satu masalah paling klasik buat siapa pun yang pernah bikin aplikasi web dengan frontend dan backend terpisah. Baru semangat-semangatnya nge-fetch data dari API, eh malah disambut tulisan merah di console yang bunyinya panjang dan bikin pusing. Di artikel ini mughu bakal bongkar tuntas kenapa error CORS ini muncul, gimana cara mendiagnosisnya, dan yang paling penting, cara mengatasi error CORS di berbagai jenis server, mulai dari Node.js, PHP, Laravel, sampai konfigurasi di Nginx dan Apache.

Singkatnya begini dulu biar langsung kebayang:

CORS adalah mekanisme keamanan bawaan browser yang membatasi sebuah halaman web mengakses sumber daya dari domain, protokol, atau port yang berbeda dari asalnya, kecuali server tujuan secara eksplisit mengizinkannya lewat header Access-Control-Allow-Origin.

Jadi begitu teman-teman lihat tulisan "blocked by CORS policy" di console, itu bukan bug di kode frontend teman-teman. Itu browser yang sedang menjalankan tugasnya sebagai penjaga gerbang.

Apa Itu CORS dan Kenapa Dia Ada di Hidup Kita

Bayangkan browser sebagai satpam kompleks perumahan. Setiap kali ada "tamu" (request dari domain lain) yang mau masuk ke "rumah" (server API), satpam ini akan cek dulu: apakah pemilik rumah memang mengundang tamu ini?

Kalau nggak ada izin tertulis, satpam menolak tamu tersebut masuk, meskipun tamunya sebenarnya nggak berniat jahat. Itulah kurang lebih cara kerja Same-Origin Policy (SOP), aturan dasar yang jadi alasan CORS itu ada.

Tiga hal yang menentukan apakah dua alamat dianggap "satu origin" atau tidak:

• Protokol — http:// beda dengan https://

• Host atau domain — toko-baju.com beda dengan api.toko-baju.com, meskipun terasa satu kesatuan

• Port — localhost:3000 beda dengan localhost:8080

Kalau salah satu dari tiga hal ini berbeda, browser langsung menganggapnya lintas origin alias cross-origin. Nah, di titik inilah CORS masuk buat mengatur siapa saja yang boleh mengakses data dari server tertentu.

Kenapa Browser Serewel Ini?

Tanpa aturan ini, website jahat yang teman-teman kunjungi bisa diam-diam mengirim request ke situs bank atau email teman-teman, memanfaatkan cookie sesi yang masih tersimpan di browser. Serangan semacam ini disebut Cross-Site Request Forgery (CSRF).

Jadi ketika browser memblokir request lintas origin yang nggak diizinkan, sebenarnya dia sedang melindungi pengguna dari kebocoran data. CORS bukan penghalang yang menyebalkan, dia justru gerbang keamanan yang bikin komunikasi antar domain di web modern jadi aman sekaligus tetap memungkinkan.

Yang Perlu Disiapkan Sebelum Mulai Membenahi CORS

Sebelum lompat ke solusi, ada beberapa hal yang sebaiknya teman-teman siapkan dulu supaya proses debugging nggak buang-buang waktu:

• Akses ke kode backend atau konfigurasi server, karena solusi CORS yang benar memang selalu ada di sisi server, bukan di frontend

• Browser dengan DevTools, Chrome, Firefox, atau Edge semuanya punya tab Network dan Console yang jadi senjata utama diagnosis

• Pemahaman dasar soal HTTP request-response, minimal tahu bedanya GET, POST, dan header request

• Terminal untuk menjalankan curl, berguna banget buat mensimulasikan request tanpa terpengaruh cache browser

• Framework atau web server yang sedang dipakai, karena cara settingnya beda-beda tergantung Express, Laravel, Nginx, atau Apache

Kalau semua itu sudah di tangan, teman-teman siap masuk ke tahap diagnosis.

Cara Mendiagnosis Error CORS Sebelum Buru-Buru Fix

Banyak orang langsung asal tempel Access-Control-Allow-Origin: * tanpa tahu akar masalahnya. Padahal diagnosis yang tepat bikin proses perbaikan jauh lebih cepat dan nggak menimbulkan lubang keamanan baru.

Langkah 1: Baca Pesan Error di Console dengan Teliti

Buka DevTools, lalu perhatikan origin mana yang diblokir dan origin mana yang diminta server. Biasanya pesannya berbunyi seperti:

Access to fetch at 'https://api.contoh.com/data' from origin 'https://app.contoh.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Dari situ teman-teman sudah tahu dua hal penting: origin pengirim request, dan origin tujuan yang menolak.

Langkah 2: Cek Tab Network

Klik request yang gagal, lihat header Request Headers untuk menemukan nilai Origin. Lalu cek Response Headers apakah ada Access-Control-Allow-Origin atau tidak.

Kalau request-nya berupa PUT, DELETE, atau membawa header custom seperti Authorization, biasanya akan ada request tambahan bermetode OPTIONS sebelum request asli dikirim. Ini disebut preflight request, semacam "tanya dulu" dari browser ke server sebelum request sungguhan dijalankan.

Langkah 3: Simulasikan dengan curl

Ini trik yang sering dilewatkan tapi sangat membantu karena curl nggak kena aturan CORS seperti browser.

curl -v -X OPTIONS https://api.contoh.com/data \
  -H "Origin: https://app.contoh.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: Content-Type, Authorization"

Kenapa langkah ini penting? Karena dari hasil curl, teman-teman bisa lihat persis header apa saja yang dikirim balik server tanpa terganggu tampilan error generik di browser. Kalau header Access-Control-Allow-Origin nggak muncul di respons curl, sudah pasti masalahnya ada di konfigurasi server, bukan di kode frontend.

Cara Mengatasi Error CORS di Node.js dengan Express

Baca juga OpenCode Free: Agen AI Coding Gratis dan Open Source

Node.js dan Express adalah kombinasi paling umum dipakai buat bikin API, jadi wajar kalau ini jadi kasus yang paling sering ditanyakan.

Langkah 1: Install Middleware cors

npm install cors

Kenapa pakai middleware ini dan bukan header manual? Karena library cors sudah menangani banyak skenario tricky, termasuk preflight request, secara otomatis dan teruji.

Langkah 2: Pasang di Aplikasi Express

const express = require("express");
const cors = require("cors");

const app = express();

const corsOptions = {
  origin: "https://app.contoh.com",
  methods: "GET,HEAD,PUT,PATCH,POST,DELETE",
  credentials: true,
};

app.use(cors(corsOptions));

app.get("/api/data", (req, res) => {
  res.json({ message: "Berhasil ambil data tanpa error CORS" });
});

app.listen(3000, () => console.log("Server jalan di port 3000"));

Expected output di terminal:

Server jalan di port 3000

Dan kalau dites dari frontend, response JSON {"message": "Berhasil ambil data tanpa error CORS"} akan muncul mulus tanpa ada tulisan merah di console.

Kesalahan yang Sering Terjadi

• Menaruh middleware cors setelah route didefinisikan. Middleware harus dipasang sebelum route supaya header sempat ditambahkan ke setiap response.

• Menggunakan origin: "*" bersamaan dengan credentials: true. Browser akan menolak kombinasi ini karena dianggap terlalu berisiko kalau request membawa cookie atau token.

• Lupa restart server setelah ubah konfigurasi. Kedengarannya sepele, tapi ini penyebab paling sering orang mengira konfigurasinya salah padahal cuma belum di-restart.

Kalau Nggak Mau Pakai Library

Bisa juga diatur manual lewat middleware biasa:

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "https://app.contoh.com");
  res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,OPTIONS");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
  if (req.method === "OPTIONS") {
    return res.sendStatus(204);
  }
  next();
});

Cara ini cocok kalau teman-teman ingin kontrol penuh, tapi risikonya lebih besar salah ketik atau lupa menangani metode OPTIONS.

Cara Mengatasi Error CORS di PHP Native

Buat yang masih pakai PHP tanpa framework, solusinya jauh lebih sederhana. Tambahkan baris ini di paling atas file endpoint API:

<?php
header("Access-Control-Allow-Origin: https://app.contoh.com");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: Content-Type, Authorization");

if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    http_response_code(204);
    exit();
}

Kenapa harus di paling atas? Karena header HTTP wajib dikirim sebelum ada output apapun, termasuk spasi atau baris kosong sekalipun. Kalau ada karakter yang ke-print duluan, PHP akan melempar warning "headers already sent" dan header CORS-nya nggak akan terkirim.

Cara Mengatasi Error CORS di Laravel

Laravel sudah menyediakan sistem CORS bawaan sejak versi 7, jadi teman-teman cukup mengedit file konfigurasi tanpa install apa-apa.

// config/cors.php
return [
    'paths' => ['api/*', 'sanctum/csrf-cookie'],
    'allowed_methods' => ['*'],
    'allowed_origins' => ['https://app.contoh.com'],
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => [],
    'max_age' => 0,
    'supports_credentials' => true,
];

Setelah itu jalankan:

php artisan config:clear

Kenapa langkah ini krusial? Laravel meng-cache file konfigurasi, jadi walaupun kode sudah benar, perubahan nggak akan terasa kalau cache lama masih dipakai. Ini salah satu penyebab paling umum orang mengira setting CORS di Laravel "nggak berfungsi" padahal sebenarnya sudah benar dari awal.

Cara Mengatasi Error CORS di Level Web Server

Kadang aplikasi backend nggak bisa diutak-atik lagi, entah karena sudah legacy atau dikelola tim lain. Solusinya bisa diambil alih dari level web server.

Konfigurasi di Nginx

location /api/ {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://app.contoh.com' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
        add_header 'Content-Length' 0;
        return 204;
    }

    add_header 'Access-Control-Allow-Origin' 'https://app.contoh.com' always;
    proxy_pass http://backend;
}

Konfigurasi di Apache lewat .htaccess

Header always set Access-Control-Allow-Origin "https://app.contoh.com"
Header always set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
Header always set Access-Control-Allow-Headers "Content-Type, Authorization"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=204,L]

Trik ini berguna banget kalau server API teman-teman berjalan di perangkat embedded atau sistem lama yang codenya susah disentuh, misalnya perangkat IoT atau sistem monitoring yang server APinya nggak fleksibel buat dikonfigurasi ulang.

Ekstensi Browser CORS: Solusi Cepat yang Wajib Dipahami Batasannya

Ada satu jalan pintas yang sering dipakai orang saat panik: pasang ekstensi browser semacam "CORS Unblock" atau sejenisnya.

Fitur utama:

• Menambahkan header Access-Control-Allow-Origin: * secara paksa ke setiap response

• Aktif atau nonaktif cukup dengan satu klik

• Nggak perlu ubah kode sama sekali

Kapan cocok dipakai:

Baca juga ClinePass: Langganan Model Open Weight untuk Coding

• Saat development lokal dan cuma teman-teman sendiri yang pakai browser tersebut

• Saat butuh cek cepat apakah masalahnya benar-benar CORS atau ada penyebab lain

• Saat testing API pihak ketiga yang belum sempat dikonfigurasi

Kelebihan:

• Instan, nggak butuh akses ke server

• Bagus buat debugging cepat

Kekurangan:

• Cuma berlaku di browser milik teman-teman sendiri, jadi nggak menyelesaikan masalah untuk pengguna lain

• Kalau lupa dimatikan, bisa bikin teman-teman salah kira bug sudah selesai padahal di production tetap error

• Nggak boleh dijadikan solusi permanen karena sama sekali nggak menyentuh akar masalah di server

Siapa yang cocok pakai: developer yang lagi proses development dan butuh workaround sementara.

Siapa yang sebaiknya menghindari: siapa pun yang berpikir ini bisa jadi solusi final untuk aplikasi yang sudah rilis ke publik.

Verdict: ekstensi ini oke banget sebagai alat bantu debugging, tapi bukan pengganti konfigurasi server yang benar. Anggap saja seperti obat pereda nyeri sementara, bukan obat yang menyembuhkan penyakitnya.

Tabel Perbandingan Metode Mengatasi Error CORS

Dari tabel ini kelihatan jelas bahwa solusi yang benar-benar aman dan tahan lama selalu melibatkan konfigurasi di sisi server, bukan trik di sisi browser.

Kapan Harus Pilih Metode yang Mana

Berikut rekomendasi berdasarkan skenario yang paling sering ditemui:

• Lagi development di localhost sendirian → pakai ekstensi browser atau atur origin ke http://localhost:3000 sementara

• API publik tanpa data sensitif → boleh pakai Access-Control-Allow-Origin: *

• API dengan autentikasi cookie atau token → wajib pakai origin spesifik, jangan pernah gabung wildcard dengan credentials: true

• Backend nggak bisa diubah → alihkan konfigurasi CORS ke level Nginx atau Apache sebagai reverse proxy

• Tim besar dengan banyak environment → buat whitelist origin dinamis yang membaca dari daftar domain yang diizinkan, lengkap dengan header Vary: Origin

Cerita dari Pengalaman Pribadi Menangani CORS di Proyek

Mughu masih ingat waktu pertama kali ketemu error ini. Waktu itu lagi bikin dashboard internal yang manggil API dari subdomain berbeda, dan mughu sempat menghabiskan hampir dua jam cuma buat sadar bahwa masalahnya bukan di kode fetch, tapi di server yang nggak mengirim header sama sekali.

Kesalahan pertama yang mughu lakukan waktu itu klasik banget: langsung tempel Access-Control-Allow-Origin: * di semua endpoint tanpa mikir panjang. Aplikasinya memang jalan, tapi begitu ditambahkan fitur login dengan cookie sesi, semua request malah gagal lagi karena kombinasi wildcard dan credentials itu memang nggak diizinkan browser.

Setelah belajar dari situ, mughu mulai membiasakan diri untuk selalu diagnosis dulu pakai curl sebelum utak-atik kode. Hasilnya, waktu debugging yang tadinya bisa berjam-jam sekarang biasanya kelar dalam hitungan menit karena sumber masalahnya sudah kelihatan jelas sejak awal.

Satu pelajaran lain yang mughu pegang sampai sekarang: jangan pernah nonaktifkan CORS sepenuhnya di production hanya demi kenyamanan sesaat. Godaan buat pakai wildcard itu besar banget waktu deadline mepet, tapi risikonya jauh lebih mahal kalau sampai ada celah keamanan yang kebobol karena origin yang terlalu longgar.

Studi Kasus Singkat: Migrasi API ke Subdomain Terpisah

Latar belakang: sebuah tim kecil memutuskan memisahkan frontend dan API mereka menjadi dua subdomain berbeda supaya lebih mudah di-scale secara terpisah.

Tantangan: begitu pemisahan dilakukan, hampir семua permintaan dari frontend ke API langsung diblokir CORS, padahal sebelumnya aplikasi berjalan normal di satu domain yang sama.

Pendekatan: tim melakukan audit endpoint mana saja yang diakses dari frontend, lalu menyusun daftar origin yang perlu diizinkan, termasuk domain staging dan domain production.

Implementasi: mereka memasang middleware cors di Express dengan origin dinamis yang membaca dari daftar whitelist, ditambah header Vary: Origin supaya cache di reverse proxy nggak salah menyimpan response untuk origin yang berbeda-beda.

Hasil: setelah konfigurasi selesai, tingkat error request API turun drastis dari yang tadinya lebih dari 30 persen kegagalan menjadi mendekati nol dalam waktu satu hari kerja, dan waktu debugging tim untuk isu terkait koneksi API berkurang signifikan karena akar masalahnya sudah ketahuan lebih awal lewat proses diagnosis yang konsisten.

Pelajaran utama: memisahkan frontend dan backend ke domain berbeda itu keputusan arsitektur yang wajar, tapi harus dibarengi rencana konfigurasi CORS sejak awal, bukan ditambal belakangan setelah error bermunculan.

Kesalahan Umum yang Bikin CORS Makin Runyam

• Menyamakan CORS dengan masalah jaringan biasa. Padahal ini murni soal izin yang diatur lewat header, bukan soal koneksi putus atau server down.

• Mengabaikan preflight request. Banyak yang cuma mengatur header untuk request utama tapi lupa menangani request OPTIONS yang datang duluan.

• Origin yang ditulis nggak persis sama, misalnya lupa menyertakan https:// atau port, sehingga browser tetap menganggapnya beda origin.

• Menggunakan reverse proxy tanpa sadar ada dua lapisan header CORS, sehingga header dari aplikasi ketimpa atau malah dobel oleh header dari Nginx.

• Menganggap masalah selesai setelah pasang ekstensi browser, padahal pengguna lain di luar browser teman-teman masih akan tetap kena blokir.

Praktik Terbaik untuk Konfigurasi CORS di Lingkungan Production

Dari sudut pandang efisiensi kerja tim dan keamanan jangka panjang, ada beberapa prinsip yang sebaiknya dijadikan standar:

• Selalu gunakan whitelist origin yang spesifik, bukan wildcard, terutama untuk API yang menangani data pengguna atau transaksi

• Batasi method dan header yang diizinkan hanya untuk yang benar-benar dipakai aplikasi, jangan asal allow all

• Tambahkan header Vary: Origin kalau origin yang diizinkan bersifat dinamis, supaya cache di CDN atau reverse proxy nggak keliru menyajikan response ke origin yang salah

• Audit ulang konfigurasi CORS setiap kali deployment besar, terutama saat menambah domain baru atau environment staging

• Dokumentasikan daftar origin yang diizinkan di satu tempat supaya tim lain nggak perlu menebak-nebak saat menambahkan integrasi baru

Dari sisi bisnis, konfigurasi CORS yang rapi juga berdampak langsung ke efisiensi tim engineering. Waktu yang tadinya dihabiskan buat debugging error yang berulang bisa dialihkan ke pengembangan fitur, dan risiko downtime akibat kesalahan konfigurasi server bisa ditekan jauh lebih rendah.

Pertanyaan yang Sering Muncul Saat Menangani CORS

Apakah CORS bisa diatasi dari sisi frontend saja? Tidak. CORS adalah aturan yang ditegakkan oleh browser berdasarkan respons dari server, jadi solusinya harus selalu melibatkan konfigurasi di backend atau web server.

Baca juga Kiro Dev: IDE Agentic AWS untuk Spec-Driven Development

Apakah aman pakai wildcard * selamanya? Aman untuk API publik yang datanya memang terbuka untuk siapa saja, tapi berbahaya untuk endpoint yang menangani autentikasi atau data pribadi.

Kenapa error masih muncul padahal header sudah ditambahkan? Biasanya karena cache konfigurasi belum dibersihkan, server belum di-restart, atau ada lapisan proxy lain yang menimpa header yang sudah diatur.

Apakah preflight request selalu terjadi di setiap request? Tidak. Preflight hanya terjadi untuk request yang dianggap "tidak sederhana", misalnya menggunakan metode selain GET/POST/HEAD, atau membawa header custom seperti Authorization.

Cara Mengatasi Error CORS di Python: Flask dan Django

Buat teman-teman yang kerja di ekosistem Python, kasusnya sedikit beda tapi konsepnya tetap sama: server harus secara eksplisit bilang "oke, origin ini boleh masuk".

Di Flask

Flask punya extension resmi bernama flask-cors yang paling banyak dipakai karena simpel dan dokumentasinya jelas.

pip install flask-cors

Setelah terpasang, tinggal import dan pasang di aplikasi:

from flask import Flask, jsonify
from flask_cors import CORS

app = Flask(__name__)
CORS(app, resources={r"/api/*": {"origins": "https://app.contoh.com"}}, supports_credentials=True)

@app.route("/api/data")
def get_data():
    return jsonify({"message": "Berhasil ambil data tanpa error CORS"})

if __name__ == "__main__":
    app.run(port=5000)

Perhatikan bagian resources. Ini berguna kalau teman-teman punya beberapa grup endpoint dengan kebijakan origin yang berbeda-beda, misalnya endpoint publik boleh diakses semua orang, tapi endpoint admin cuma boleh dari domain internal.

Kesalahan yang sering kejadian di Flask:

• Lupa install flask-cors dan malah nulis header manual pakai after_request, padahal itu bisa dilakukan tapi rawan bentrok kalau ada dua mekanisme jalan bersamaan

• Menaruh CORS(app) tanpa parameter apapun di aplikasi yang sudah pakai autentikasi, sehingga origin jadi wildcard dan bikin celah keamanan

• Nggak menyesuaikan resources dengan prefix URL API yang sebenarnya dipakai, jadi header cuma nempel di sebagian endpoint saja

Di Django

Django sedikit lebih ribet karena punya sistem middleware yang urutannya harus benar-benar diperhatikan. Install dulu:

pip install django-cors-headers

Lalu tambahkan ke INSTALLED_APPS dan MIDDLEWARE di settings.py:

INSTALLED_APPS = [
    # aplikasi lain...
    "corsheaders",
]

MIDDLEWARE = [
    "corsheaders.middleware.CorsMiddleware",
    "django.middleware.common.CommonMiddleware",
    # middleware lain...
]

CORS_ALLOWED_ORIGINS = [
    "https://app.contoh.com",
]

CORS_ALLOW_CREDENTIALS = True

Kenapa urutan middleware ini penting banget? Karena CorsMiddleware harus diletakkan di posisi yang lebih tinggi daripada middleware lain yang bisa menghasilkan response, terutama CommonMiddleware. Kalau urutannya salah, header CORS bisa saja nggak sempat ditambahkan ke response akhir, dan teman-teman akan bingung kenapa konfigurasi yang kelihatannya sudah benar tetap nggak berefek.

Satu hal yang sering bikin orang garuk-garuk kepala di Django adalah perbedaan antara CORS_ALLOWED_ORIGINS dan CORS_ALLOW_ALL_ORIGINS. Yang kedua ini kalau di-set True akan mengizinkan semua origin, mirip wildcard, jadi sebaiknya cuma dipakai saat development lokal saja.

Cara Mengatasi Error CORS di Spring Boot

Buat tim yang pakai Java dengan Spring Boot, penanganannya bisa dilakukan lewat anotasi sederhana atau konfigurasi global tergantung skala aplikasinya.

Cara paling cepat, tinggal tambahkan anotasi di controller:

@RestController
@RequestMapping("/api")
@CrossOrigin(origins = "https://app.contoh.com")
public class DataController {

    @GetMapping("/data")
    public Map<String, String> getData() {
        return Map.of("message", "Berhasil ambil data tanpa error CORS");
    }
}

Cara ini praktis tapi kurang ideal kalau aplikasi punya banyak controller, karena teman-teman harus menempel anotasi yang sama berulang-ulang di setiap file. Solusi yang lebih rapi adalah bikin konfigurasi global:

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://app.contoh.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

Kenapa pendekatan global ini lebih disarankan? Karena aturan CORS jadi terpusat di satu file, gampang diaudit, dan nggak ada risiko ada satu controller yang kelupaan dikasih anotasi sehingga tetap kena blokir padahal endpoint lain sudah aman.

Kalau aplikasi Spring Boot teman-teman menggunakan Spring Security, ada satu jebakan klasik yang sering bikin orang bingung: konfigurasi CORS di WebMvcConfigurer itu nggak otomatis dipakai kalau Spring Security aktif. Teman-teman perlu menambahkan konfigurasi CORS terpisah di dalam SecurityFilterChain, karena Spring Security punya lapisan filter sendiri yang dieksekusi lebih dulu sebelum request sampai ke controller.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.cors(cors -> cors.configurationSource(corsConfigurationSource()));
    return http.build();
}

@Bean
public CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration configuration = new CorsConfiguration();
    configuration.setAllowedOrigins(List.of("https://app.contoh.com"));
    configuration.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE", "OPTIONS"));
    configuration.setAllowCredentials(true);

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", configuration);
    return source;
}

Cara Mengatasi Error CORS di ASP.NET Core

Baca juga Codex CLI dari OpenAI: Panduan Lengkap Ngoding di Terminal

Buat teman-teman yang pakai stack .NET, ASP.NET Core juga sudah menyediakan sistem CORS bawaan yang cukup lengkap sejak versi awal .NET Core.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowFrontend", policy =>
    {
        policy.WithOrigins("https://app.contoh.com")
              .AllowAnyMethod()
              .AllowAnyHeader()
              .AllowCredentials();
    });
});

var app = builder.Build();

app.UseCors("AllowFrontend");

app.MapGet("/api/data", () => new { message = "Berhasil ambil data tanpa error CORS" });

app.Run();

Ada satu urutan yang wajib diperhatikan di sini: app.UseCors() harus dipanggil setelah app.UseRouting() (kalau dipakai secara eksplisit) tapi sebelum app.UseAuthorization(). Kalau urutannya kebalik, header CORS bisa saja nggak sempat ditambahkan sebelum request diproses lebih jauh, dan hasilnya ya balik lagi ke error yang sama meskipun konfigurasinya sudah kelihatan benar di mata teman-teman.

CORS di Level Reverse Proxy dan API Gateway Modern

Selain Nginx dan Apache yang sudah dibahas sebelumnya, banyak tim sekarang menaruh lapisan tambahan berupa API Gateway atau CDN di depan backend mereka. Ini bikin penanganan CORS jadi sedikit lebih rumit karena ada lebih dari satu titik yang berpotensi menambahkan atau malah menghapus header.

Cloudflare

Kalau teman-teman pakai Cloudflare sebagai proxy di depan server, ada fitur bernama Transform Rules yang bisa dipakai buat menambahkan header CORS tanpa harus menyentuh kode backend sama sekali. Caranya lewat dashboard Cloudflare, masuk ke bagian Rules, lalu bikin aturan yang menambahkan header Access-Control-Allow-Origin berdasarkan kondisi path tertentu.

Kelebihan pendekatan ini:

• Nggak perlu deploy ulang aplikasi backend

• Bisa diterapkan langsung untuk banyak subdomain sekaligus

• Ada fitur caching bawaan yang bisa mempercepat response, asalkan header Vary: Origin diatur dengan benar

Kekurangannya:

• Kalau backend juga mengirim header CORS-nya sendiri, bisa terjadi duplikasi header yang justru bikin browser menolak response karena nilainya jadi ambigu

• Butuh langganan tertentu untuk mengakses fitur Transform Rules yang lebih fleksibel

AWS API Gateway

Di AWS API Gateway, pengaturan CORS biasanya dilakukan lewat konsol atau lewat definisi OpenAPI/Swagger. Kalau pakai REST API, teman-teman perlu mengaktifkan CORS di setiap resource dan memastikan method OPTIONS sudah terdaftar sebagai mock integration yang mengembalikan header yang sesuai.

Satu hal yang sering jadi jebakan di sini adalah lupa mendeploy ulang API setelah mengubah pengaturan CORS. Berbeda dengan server biasa yang cukup di-restart, API Gateway punya konsep "stage" yang harus di-deploy ulang secara eksplisit supaya perubahan konfigurasi benar-benar aktif di endpoint yang dipakai production.

Kenapa Lapisan Proxy Bikin CORS Lebih Rumit

Semakin banyak lapisan antara browser dan aplikasi backend yang sebenarnya, semakin besar juga kemungkinan header CORS "hilang di tengah jalan" atau malah tertimpa dua kali. Prinsip yang sebaiknya dipegang: tentukan satu titik yang jadi "sumber kebenaran" untuk header CORS, entah itu di aplikasi backend atau di lapisan proxy, lalu pastikan lapisan lain nggak ikut menambahkan header yang sama supaya nggak terjadi konflik.

CORS untuk WebSocket dan Server-Sent Events

Ini bagian yang sering dilewatkan banyak tutorial, padahal cukup penting buat aplikasi real-time seperti chat atau notifikasi live.

Kabar baiknya, WebSocket sebenarnya nggak tunduk pada aturan CORS dengan cara yang sama seperti request HTTP biasa. Koneksi WebSocket memang tetap mengirim header Origin saat proses handshake awal, tapi validasinya sepenuhnya diserahkan ke server, bukan dipaksa oleh browser lewat mekanisme Access-Control-Allow-Origin.

Artinya, kalau server WebSocket teman-teman nggak melakukan pengecekan origin sama sekali, secara teknis semua origin bisa terhubung. Ini kedengarannya praktis, tapi justru berisiko kalau aplikasi menangani data sensitif.

Contoh validasi origin manual di server WebSocket berbasis Node.js dengan library ws:

const WebSocket = require("ws");

const allowedOrigins = ["https://app.contoh.com"];

const wss = new WebSocket.Server({ port: 8080 });

wss.on("connection", (socket, req) => {
  const origin = req.headers.origin;
  if (!allowedOrigins.includes(origin)) {
    socket.close(1008, "Origin tidak diizinkan");
    return;
  }

  socket.on("message", (message) => {
    console.log(`Pesan diterima dari ${origin}: ${message}`);
  });
});

Kenapa validasi ini penting? Karena tanpa pengecekan origin, siapa saja bisa membuat halaman web sendiri yang membuka koneksi WebSocket ke server teman-teman dan mengirim data seolah-olah berasal dari aplikasi resmi. Ini bukan celah CORS dalam arti teknis, tapi tetap saja celah keamanan yang harus ditutup secara manual karena browser nggak akan otomatis menjaganya seperti pada request HTTP biasa.

Untuk Server-Sent Events (SSE), situasinya justru lebih mirip request HTTP biasa karena SSE dibangun di atas koneksi HTTP standar. Jadi aturan CORS yang sama seperti request GET biasa tetap berlaku, dan server harus mengirim header Access-Control-Allow-Origin yang sesuai supaya browser mengizinkan koneksi EventSource dari origin yang berbeda.

CORS dan GraphQL: Kasus yang Sedikit Berbeda

Buat teman-teman yang bekerja dengan GraphQL, penanganan CORS sebenarnya nggak jauh beda dari REST API biasa, karena pada akhirnya request GraphQL tetap dikirim lewat HTTP, biasanya dengan method POST ke satu endpoint tunggal seperti /graphql.

Yang bikin sedikit beda adalah header yang dipakai. Klien GraphQL populer seperti Apollo Client sering menyertakan header custom seperti apollo-require-preflight atau header autentikasi di setiap request, yang otomatis memicu preflight request. Jadi server GraphQL wajib menangani method OPTIONS dengan benar dan mengizinkan header-header tersebut secara eksplisit.

Contoh konfigurasi di Apollo Server berbasis Express:

const { ApolloServer } = require("@apollo/server");
const { expressMiddleware } = require("@apollo/server/express4");
const cors = require("cors");
const express = require("express");

const app = express();
const server = new ApolloServer({ typeDefs, resolvers });

await server.start();

app.use(
  "/graphql",
  cors({
    origin: "https://app.contoh.com",
    credentials: true,
  }),
  express.json(),
  expressMiddleware(server)
);

Satu kesalahan umum yang sering muncul di kasus GraphQL adalah menganggap satu endpoint tunggal berarti konfigurasi CORS-nya lebih sederhana. Padahal karena semua operasi—query, mutation, subscription—lewat satu pintu yang sama, kalau konfigurasi CORS-nya salah, seluruh fungsi aplikasi bisa langsung lumpuh sekaligus, bukan cuma satu fitur saja seperti pada REST API yang endpoint-nya terpisah-pisah.

Baca juga CodeBuddy: Editor Kode AI untuk Coding Lebih Cepat

Tools yang Membantu Proses Debugging CORS

Selain curl yang sudah dibahas di awal, ada beberapa alat lain yang layak masuk daftar andalan teman-teman.

Postman

Postman sering dianggap cuma buat testing API biasa, padahal alat ini juga berguna banget buat simulasi preflight request. Bedanya dengan curl, Postman punya antarmuka visual yang bikin teman-teman lebih gampang melihat header request dan response secara berdampingan.

Kelebihan:

• Antarmuka visual yang ramah dipakai, cocok buat tim yang nggak semua anggotanya nyaman dengan command line

• Bisa menyimpan koleksi request buat dites ulang kapan saja

• Punya fitur environment variable yang memudahkan berpindah antara staging dan production

Kekurangan:

• Postman secara default nggak menegakkan kebijakan CORS seperti browser, jadi request yang berhasil di Postman belum tentu otomatis berhasil juga di browser

• Versi gratisnya punya batasan jumlah request tersimpan dan kolaborasi tim

Browser DevTools Network Conditions

Selain tab Network yang sudah dibahas, Chrome DevTools juga punya fitur untuk menyimulasikan berbagai kondisi jaringan sekaligus memfilter request berdasarkan tipe, termasuk request OPTIONS yang biasanya tersembunyi di antara request lain kalau nggak difilter.

Ekstensi "CORS Test"

Ada beberapa ekstensi ringan yang fungsinya khusus buat menampilkan status CORS dari sebuah endpoint tanpa harus membuka DevTools sama sekali. Cukup masukkan URL, dan ekstensi akan menunjukkan header apa saja yang dikembalikan server.

Verdict: kombinasi curl untuk pengecekan cepat dan mendalam, plus Postman untuk dokumentasi dan kolaborasi tim, biasanya sudah cukup buat menangani hampir semua kasus debugging CORS sehari-hari. Ekstensi browser lebih cocok buat pengecekan super cepat saat teman-teman lagi terburu-buru dan cuma butuh jawaban ya atau tidak.

Perbandingan Library CORS di Berbagai Bahasa Pemrograman

Biar teman-teman punya gambaran lebih luas, berikut perbandingan singkat pendekatan CORS di beberapa ekosistem yang paling umum dipakai tim pengembang di Indonesia.

Dari tabel ini kelihatan bahwa hampir semua framework modern sudah menyediakan cara resmi buat menangani CORS. Tantangan terbesar biasanya bukan soal susah atau nggaknya konfigurasi, tapi soal ketelitian dalam urutan pemasangan middleware dan konsistensi origin yang didaftarkan.

Mengatasi CORS di Layanan Hosting Lokal Indonesia

Buat teman-teman yang masih pakai layanan shared hosting lokal seperti yang banyak ditawarkan provider-provider hosting Indonesia, penanganan CORS biasanya sedikit lebih terbatas dibanding server yang dikelola sendiri, karena akses ke konfigurasi tingkat server sering dibatasi oleh panel hosting seperti cPanel.

Kabar baiknya, hampir semua layanan hosting berbasis cPanel tetap mengizinkan penggunaan file .htaccess, jadi solusi Apache yang sudah dibahas sebelumnya tetap bisa dipakai tanpa perlu akses root.

Beberapa catatan khusus buat pengguna hosting lokal:

• Pastikan modul mod_headers aktif. Kalau header CORS nggak muncul sama sekali padahal .htaccess sudah benar, kemungkinan besar modul ini belum diaktifkan oleh provider hosting, dan teman-teman perlu menghubungi support untuk memastikannya

• Cek apakah hosting menggunakan LiteSpeed, bukan Apache murni. Banyak hosting lokal sekarang beralih ke LiteSpeed karena performanya lebih ringan, dan meskipun kompatibel dengan sebagian besar sintaks .htaccess Apache, ada beberapa direktif yang perlu penyesuaian

• Perhatikan batasan resource pada paket shared hosting. Kalau aplikasi API teman-teman menerima banyak request preflight sekaligus, paket hosting dengan resource terbatas kadang memperlambat response, yang bisa disalahartikan sebagai masalah CORS padahal sebenarnya masalah performa server

Kalau aplikasi sudah mulai berkembang dan butuh kontrol penuh terhadap konfigurasi server, banyak tim akhirnya bermigrasi ke VPS atau cloud hosting supaya bisa mengatur Nginx atau Apache secara langsung sesuai kebutuhan, termasuk urusan CORS yang lebih kompleks seperti whitelist origin dinamis.

Studi Kasus Kedua: Startup Lokal yang Pindah ke Arsitektur Microservices

Latar belakang: sebuah startup rintisan di bidang logistik memutuskan memecah aplikasi monolitik mereka menjadi beberapa layanan terpisah, masing-masing menangani modul berbeda seperti pelacakan pengiriman, manajemen gudang, dan layanan pembayaran.

Tantangan: setelah pemecahan ini, frontend yang sebelumnya cuma bicara dengan satu backend, sekarang harus berkomunikasi dengan lima layanan berbeda yang masing-masing berjalan di subdomain atau port yang berlainan saat development. Tim menghadapi lonjakan tiket dukungan internal soal error CORS yang muncul di hampir semua modul secara bersamaan begitu proses migrasi dimulai.

Pendekatan: alih-alih mengatur CORS satu per satu di setiap layanan, tim memutuskan membangun satu API Gateway sebagai pintu masuk tunggal. Semua request dari frontend diarahkan ke gateway ini, dan gateway yang bertugas meneruskan request ke layanan yang sesuai di belakang layar.

Implementasi: konfigurasi CORS cukup dipasang sekali di level gateway menggunakan pendekatan whitelist origin dinamis, sehingga setiap layanan di baliknya nggak perlu lagi memikirkan urusan CORS sama sekali karena semua request yang sampai ke mereka sudah dianggap berasal dari satu origin internal yang dipercaya.

Hasil: jumlah tiket terkait error CORS turun drastis dalam waktu kurang dari satu minggu setelah gateway diterapkan, dan tim engineering bisa fokus mengembangkan fitur baru di masing-masing layanan tanpa harus berulang kali mengatur kebijakan origin yang sama di banyak tempat berbeda.

Pelajaran utama: semakin kompleks arsitektur sebuah aplikasi, semakin penting untuk memusatkan pengelolaan CORS di satu titik strategis, alih-alih menyebarkannya ke banyak layanan kecil yang masing-masing punya konfigurasi sendiri-sendiri dan rawan nggak konsisten.

Monitoring dan Logging untuk Masalah CORS

Salah satu hal yang jarang dibahas tapi cukup krusial buat aplikasi skala production adalah bagaimana cara memantau error CORS secara proaktif, bukan cuma menunggu laporan dari pengguna atau tim frontend.

Baca juga GitHub Copilot: Cara Mempercepat Kerja Tim

Kenapa Monitoring Ini Penting

Error CORS terjadi sepenuhnya di sisi browser, artinya server sebenarnya nggak "tahu" kalau response yang dia kirim ditolak oleh browser pengguna. Dari sudut pandang server, request tersebut tetap dianggap berhasil diproses, padahal pengguna di ujung sana melihat aplikasi yang gagal total.

Cara Sederhana Memantau

Salah satu pendekatan yang bisa dipakai adalah menambahkan logging khusus di middleware CORS untuk mencatat setiap request yang datang dari origin yang nggak ada di daftar whitelist. Dengan begini, teman-teman bisa tahu origin mana saja yang mencoba mengakses API tapi ditolak, tanpa harus menunggu laporan manual.

app.use((req, res, next) => {
  const origin = req.headers.origin;
  const allowedOrigins = ["https://app.contoh.com"];

  if (origin && !allowedOrigins.includes(origin)) {
    console.warn(`Percobaan akses ditolak dari origin: ${origin} pada ${new Date().toISOString()}`);
  }

  next();
});

Log semacam ini bisa dikirim ke layanan monitoring seperti yang biasa dipakai tim engineering untuk memantau error aplikasi, sehingga kalau ada lonjakan percobaan akses dari origin yang mencurigakan, tim bisa langsung mendapat notifikasi alih-alih baru sadar setelah masalah membesar.

Menggunakan Error Tracking di Sisi Frontend

Di sisi frontend, teman-teman juga bisa menangkap error fetch yang berkaitan dengan CORS dan mengirimkannya ke layanan pelacakan error. Meskipun pesan error CORS yang ditangkap lewat JavaScript biasanya cuma berupa TypeError: Failed to fetch tanpa detail spesifik karena alasan keamanan browser, setidaknya teman-teman bisa tahu frekuensi kegagalan ini terjadi dan endpoint mana yang paling sering bermasalah.

Menguji Konfigurasi CORS Secara Otomatis di CI/CD

Buat tim yang sudah menerapkan continuous integration, ada baiknya pengujian CORS dimasukkan sebagai bagian dari pipeline otomatis, bukan cuma dicek manual setiap kali deploy.

Contoh sederhana pengujian menggunakan Jest dan library supertest di aplikasi Express:

const request = require("supertest");
const app = require("../app");

describe("Konfigurasi CORS", () => {
  it("harus mengizinkan origin yang terdaftar", async () => {
    const response = await request(app)
      .options("/api/data")
      .set("Origin", "https://app.contoh.com")
      .set("Access-Control-Request-Method", "GET");

    expect(response.headers["access-control-allow-origin"]).toBe(
      "https://app.contoh.com"
    );
  });

  it("harus menolak origin yang tidak terdaftar", async () => {
    const response = await request(app)
      .options("/api/data")
      .set("Origin", "https://situs-asing.com")
      .set("Access-Control-Request-Method", "GET");

    expect(response.headers["access-control-allow-origin"]).toBeUndefined();
  });
});

Kenapa pengujian otomatis ini bermanfaat? Karena perubahan kecil di kode, misalnya refactor middleware atau upgrade dependency, kadang tanpa sengaja mengubah perilaku CORS tanpa disadari siapa pun sampai muncul laporan dari pengguna. Dengan pengujian otomatis, kesalahan semacam ini bisa ketahuan sejak tahap pipeline, jauh sebelum kode sempat naik ke production.

Tim yang sudah matang biasanya juga menambahkan pengujian serupa untuk memastikan kombinasi wildcard dan credentials: true nggak pernah lolos ke production secara nggak sengaja, mengingat kombinasi ini adalah salah satu kesalahan konfigurasi paling umum yang sudah dibahas di bagian awal artikel ini.

Checklist Lengkap Sebelum Deploy Konfigurasi CORS ke Production

Supaya nggak ada langkah yang terlewat, berikut daftar yang bisa teman-teman jadikan acuan setiap kali akan mendorong perubahan konfigurasi CORS ke lingkungan production:

• Origin yang diizinkan sudah spesifik, bukan wildcard, terutama untuk endpoint yang menangani data pengguna

• Kombinasi wildcard dan credentials: true sudah dipastikan tidak pernah terjadi di satu konfigurasi yang sama

• Method yang diizinkan sudah dibatasi hanya yang benar-benar dipakai aplikasi

• Header custom yang diizinkan sudah didaftarkan secara eksplisit, bukan asal allow all

• Header Vary: Origin sudah ditambahkan kalau daftar origin bersifat dinamis

• Semua lapisan, baik aplikasi maupun reverse proxy, sudah dicek supaya nggak ada header CORS yang double atau saling menimpa

• Pengujian otomatis CORS sudah dijalankan dan lolos di pipeline CI/CD

• Domain staging dan production sudah didaftarkan secara terpisah sesuai kebutuhan masing-masing environment

• Dokumentasi daftar origin yang diizinkan sudah diperbarui supaya tim lain nggak perlu menebak-nebak

• Sudah ada mekanisme monitoring atau logging untuk memantau percobaan akses dari origin yang nggak terdaftar

Checklist semacam ini kelihatan sepele, tapi dari pengalaman mughu menangani berbagai proyek, langkah-langkah kecil yang konsisten dijalankan justru yang paling efektif mencegah masalah besar muncul belakangan. Kebanyakan insiden CORS yang parah di production itu bukan karena masalah teknis yang rumit, tapi karena ada satu langkah sederhana yang kelewat dicek.

Pertanyaan Tambahan Seputar Penanganan CORS

Apakah CORS berlaku juga untuk request dari aplikasi mobile? Tidak. Aturan CORS murni ditegakkan oleh browser, jadi aplikasi native di Android atau iOS yang memanggil API secara langsung nggak terkena pembatasan ini sama sekali. Kalau ada error mirip CORS di aplikasi mobile, biasanya penyebabnya lain, misalnya masalah sertifikat SSL atau konfigurasi jaringan.

Kenapa request dari Postman berhasil tapi dari browser gagal? Karena Postman nggak menjalankan mekanisme keamanan CORS seperti browser. Jadi kalau request di Postman lancar tapi di browser diblokir, itu justru pertanda kuat bahwa masalahnya benar-benar soal konfigurasi CORS di server, bukan soal server yang mati atau salah endpoint.

Apakah menambahkan banyak origin ke whitelist bikin server jadi lambat? Secara praktik, dampaknya biasanya sangat kecil karena proses pengecekan origin cuma berupa pencocokan string sederhana. Yang lebih berpengaruh ke performa justru jumlah request preflight yang berulang-ulang, dan ini bisa diatasi dengan mengatur max_age yang sesuai supaya browser menyimpan hasil preflight sementara waktu dan nggak perlu mengirim ulang setiap saat.

Apakah aman menyimpan daftar origin di environment variable? Sangat disarankan malah, karena dengan begitu teman-teman nggak perlu mengubah kode setiap kali ada penambahan domain baru, cukup memperbarui nilai environment variable di server dan me-restart aplikasi.

Bagaimana menangani CORS untuk API yang dipakai banyak partner eksternal dengan domain berbeda-beda? Pendekatan paling umum adalah menyimpan daftar domain partner di database atau file konfigurasi, lalu memvalidasi origin request secara dinamis terhadap daftar tersebut, bukan menuliskannya secara hardcode di kode aplikasi. Ini memudahkan proses penambahan atau pencabutan akses partner tanpa perlu deploy ulang seluruh aplikasi.

Apakah CORS bisa dipakai sebagai satu-satunya lapisan keamanan API? Tidak sebaiknya. CORS hanya mengatur browser mana yang boleh membaca response, tapi nggak menghalangi request dikirim lewat cara lain seperti curl atau aplikasi server-to-server. Untuk keamanan yang benar-benar solid, CORS harus dibarengi dengan autentikasi yang layak, seperti token atau API key, supaya data tetap terlindungi meskipun ada pihak yang mencoba mengakses API dari luar browser.

Kenapa error CORS kadang cuma muncul di production tapi nggak di lokal? Ini biasanya terjadi karena origin yang didaftarkan di server cuma mencakup localhost, sementara domain production yang sebenarnya dipakai belum ditambahkan ke whitelist. Ini juga alasan kenapa penting banget punya daftar origin terpisah untuk tiap environment, supaya nggak ada yang kelupaan saat aplikasi naik ke tahap production.

Kalau teman-teman sudah sampai di titik ini, artinya sudah punya bekal yang cukup lengkap buat menangani hampir semua skenario error CORS yang mungkin ditemui, mulai dari kasus paling sederhana di satu server Express, sampai arsitektur rumit dengan banyak layanan dan lapisan proxy sekaligus. Yang paling penting untuk selalu diingat, akar masalah CORS itu hampir selalu ada di konfigurasi server, dan solusi jangka panjang yang benar-benar aman selalu melibatkan pengaturan origin yang spesifik, bukan jalan pintas yang mengorbankan keamanan demi kenyamanan sesaat.

Cara Mengatasi Error CORS di Next.js dan Platform Serverless

Ekosistem serverless kayak Vercel dan Netlify punya karakteristik yang agak beda dari server tradisional, karena setiap function dijalankan secara terpisah dan kadang nggak ada satu titik pusat yang gampang dijadikan tempat pasang middleware global.

Kalau teman-teman pakai Next.js dengan App Router, cara paling gampang adalah menambahkan header langsung di dalam Route Handler:

Baca juga Mengenal Astro 7.1: Framework JavaScript Ringan untuk Website

export async function GET(request) {
  return Response.json(
    { message: "Berhasil ambil data tanpa error CORS" },
    {
      headers: {
        "Access-Control-Allow-Origin": "https://app.contoh.com",
        "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
      },
    }
  );
}

export async function OPTIONS() {
  return new Response(null, {
    status: 204,
    headers: {
      "Access-Control-Allow-Origin": "https://app.contoh.com",
      "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
      "Access-Control-Allow-Headers": "Content-Type, Authorization",
    },
  });
}

Alternatifnya, kalau nggak mau nulis header ini di setiap route satu-satu, Next.js juga menyediakan konfigurasi header global lewat file next.config.js. Ini lebih rapi kalau kebutuhan CORS-nya seragam di semua endpoint API.

Buat teman-teman yang pakai Netlify Functions, penanganannya mirip, tinggal tambahkan header di object response yang dikembalikan function-nya. Yang perlu diingat, karena tiap function berdiri sendiri, gampang banget kejadian satu function udah dikasih header CORS tapi function lain kelupaan. Makanya bikin satu file utilitas kecil berisi konfigurasi header yang dipakai bersama itu langkah yang worth banget diambil sejak awal, biar nggak ada yang tercecer.

Kenapa Safari Kadang Bertingkah Beda Soal CORS

Ini satu hal yang bikin banyak developer garuk-garuk kepala: konfigurasi CORS yang jalan mulus di Chrome, eh pas dites di Safari malah bermasalah, terutama kalau aplikasi mengandalkan cookie lintas domain.

Penyebabnya bukan CORS itu sendiri, tapi fitur bernama Intelligent Tracking Prevention (ITP) yang cukup agresif membatasi cookie pihak ketiga. Jadi meskipun header Access-Control-Allow-Origin dan Access-Control-Allow-Credentials sudah benar, Safari tetap bisa menolak menyimpan atau mengirim cookie kalau domain frontend dan backend dianggap "pihak ketiga" satu sama lain.

Solusi yang paling umum dipakai adalah mengatur atribut cookie SameSite=None; Secure, sehingga browser tahu cookie tersebut memang sengaja dipakai lintas domain dan bukan cookie pelacak. Tapi perlu dicatat, atribut Secure mewajibkan koneksi HTTPS, jadi trik ini nggak akan berfungsi kalau aplikasi masih jalan di http:// biasa.

Kalau memang memungkinkan, pendekatan yang lebih aman dan lebih gampang dari sisi kompatibel antar browser adalah menaruh frontend dan backend di bawah domain utama yang sama, misalnya app.toko-baju.com dan api.toko-baju.com, lalu memakai reverse proxy supaya dari sudut pandang browser semuanya terasa satu origin. Cara ini otomatis menghindari banyak drama soal cookie lintas domain.

Memangkas Jumlah Preflight dengan Access-Control-Max-Age

Satu detail kecil yang sering kelewat tapi lumayan berpengaruh ke performa adalah header Access-Control-Max-Age. Header ini memberi tahu browser berapa lama hasil preflight boleh disimpan di cache, sehingga request OPTIONS yang sama nggak perlu dikirim ulang setiap kali ada request baru ke endpoint yang sama.

res.header("Access-Control-Max-Age", "86400");

Angka di atas berarti browser boleh menyimpan hasil preflight selama satu hari penuh. Buat aplikasi dengan trafik tinggi yang sering memanggil endpoint sama berkali-kali, ini bisa memangkas jumlah request OPTIONS secara signifikan, yang ujung-ujungnya bikin aplikasi terasa lebih responsif buat pengguna.

Perlu diingat juga, tiap browser punya batas maksimum sendiri buat nilai ini. Chrome misalnya membatasi maksimal sekitar dua jam meskipun teman-teman set angka yang lebih besar, jadi jangan berharap nilai raksasa bakal langsung dipatuhi sepenuhnya oleh semua browser.

Audit Keamanan CORS yang Sering Luput dari Perhatian Tim

Salah satu kesalahan konfigurasi yang paling sering ditemukan saat audit keamanan adalah praktik "merefleksikan" origin, yaitu server secara otomatis mengembalikan nilai header Origin yang dikirim browser sebagai nilai Access-Control-Allow-Origin, tanpa validasi terhadap whitelist sama sekali.

// Pola berbahaya, jangan ditiru
res.header("Access-Control-Allow-Origin", req.headers.origin);

Kelihatannya praktis karena otomatis "mengizinkan semua origin" tanpa perlu daftar manual, tapi efeknya sama persis dengan wildcard, cuma dibungkus supaya kelihatan lebih aman. Kalau ini digabung dengan credentials: true, situasinya jadi jauh lebih berbahaya karena origin mana pun yang mengirim request akan otomatis dianggap tepercaya, termasuk domain yang sengaja dibuat orang jahat buat mencuri data lewat cookie sesi pengguna.

Tim keamanan yang melakukan audit biasanya juga mengecek origin null, yang muncul pada kondisi tertentu seperti request dari file lokal atau sandbox iframe. Kalau server ternyata mengizinkan origin null masuk whitelist, itu celah yang gampang banget dieksploitasi. Jadi selain daftar domain yang jelas, pastikan juga validasi origin dilakukan lewat pencocokan string yang ketat, bukan sekadar mengecek apakah header Origin itu ada atau nggak.

Kesimpulan

Menangani error CORS sebenarnya bukan soal menghafal satu header ajaib, melainkan memahami bagaimana browser, server, dan cookie saling bernegosiasi soal kepercayaan antar origin. Dari pembahasan di atas, terlihat jelas bahwa solusi cepat seperti mengatur atribut cookie lintas domain hanya efektif kalau prasyaratnya terpenuhi, terutama koneksi HTTPS lewat atribut Secure. Kalau infrastruktur memungkinkan, menyatukan frontend dan backend di bawah domain utama yang sama lewat reverse proxy tetap jadi pendekatan paling tahan lama, karena menghilangkan akar masalah alih-alih terus-menerus menambal gejalanya.

Di sisi performa, detail sekecil Access-Control-Max-Age sering diremehkan padahal dampaknya nyata buat aplikasi bertrafik tinggi. Mengatur cache preflight dengan tepat, sambil tetap sadar akan batasan masing-masing browser, adalah contoh optimisasi kecil yang hasilnya terasa besar di pengalaman pengguna. Namun performa saja tidak cukup kalau keamanannya keropos. Praktik merefleksikan header Origin secara otomatis, apalagi digabung dengan credentials: true, adalah jebakan yang kelihatan praktis tapi sebenarnya membuka pintu lebar-lebar bagi origin berbahaya, termasuk celah dari origin null yang kerap luput dari pengecekan.

Pada akhirnya, konfigurasi CORS yang sehat adalah hasil dari keseimbangan antara kemudahan pengembangan, performa, dan kedisiplinan validasi origin. Jangan tergoda jalan pintas yang terlihat "beres" di lingkungan development tapi menyimpan risiko besar begitu diterapkan ke production. Coba audit ulang konfigurasi CORS di proyekmu sekarang juga, mumpung semua poin di atas masih segar di ingatan, sebelum celah kecil itu berubah jadi masalah keamanan yang jauh lebih mahal untuk diperbaiki.

Referensi

Codepolitan. (2026). Solusi Ampuh Mengatasi Error CORS yang Bikin Pusing Developer.

GitHub. (2026). Panduan Singkat Mengatasi CORS di Berbagai Macam Aplikasi.

CloudAja. (2026). Solusi Ampuh Mengatasi Error CORS.

Dicoding. (2026). Memahami dan Memperbaiki Konfigurasi Header CORS Error.

Baca juga 9Router v0.5.35: Solusi Rate Limit AI Coding

Medium. (2026). Memahami CORS: Definisi, Penyebab, dan Cara Mengatasinya (Node.js).

Medium. (2026). Mengenal CORS: Definisi, Cara Mengatasi, dan Implementasi dengan CrootJS.

Bekasi.dev. (2026). Error CORS: Penyebab dan Cara Fix Lengkap.

Hasan.dev. (2026). Memahami CORS: Mengatasi Masalah Cross-Origin di Aplikasi Web Anda.

GSI Indo. (2026). Penyebab CORS Header Access-Control-Allow-Origin Missing.

Reza in Programming. (2026). 3 Cara Memperbaiki CORS Error dan Cara Kerja Header Access-Control-Allow-Origin.