All Products
Search
Document Center

Object Storage Service:Konfigurasikan Berbagi Sumber Daya Lintas Asal (CORS)

Last Updated:Sep 09, 2026

Browser dapat memblokir permintaan lintas asal ke Object Storage Service (OSS) karena kebijakan asal sama, yang membatasi akses hanya pada protokol, domain, dan port yang identik. Misalnya, halaman di https://www.example.com tidak dapat memuat sumber daya dari https://example-bucket.oss-cn-hangzhou.aliyuncs.com/test.jpg.imageKonfigurasikan aturan CORS untuk bucket Anda agar website tertentu dapat mengakses sumber daya OSS secara langsung.

Cara kerja

Permintaan CORS terbagi menjadi dua jenis: permintaan simple (dikirim langsung) dan permintaan preflight (memerlukan pemeriksaan otorisasi sebelum permintaan utama).

Permintaan preflight diperlukan jika salah satu kondisi berikut terpenuhi:

  • Permintaan menggunakan metode selain GET, HEAD, atau POST.

  • Permintaan menggunakan metode POST dengan Content-Type selain text/plain, application/x-www-form-urlencoded, atau multipart/form-data.

  • Permintaan menyertakan header kustom, seperti x-oss-*.

Saat browser mengirim permintaan simple ke OSS, proses berikut terjadi:

  1. Browser menambahkan header Origin ke permintaan. Header Origin menentukan asal halaman pemanggil, misalnya, Origin: https://www.example.com.

  2. OSS memeriksa metode HTTP dan header Origin permintaan terhadap aturan CORS bucket untuk mencari aturan yang sesuai. Jika ditemukan kecocokan, OSS menyertakan header Access-Control-Allow-Origin dalam respons. Nilai header ini sama dengan nilai header Origin dari permintaan awal.

  3. Browser menerima respons tersebut. Browser hanya mengizinkan permintaan dilanjutkan jika header Access-Control-Allow-Origin ada dan nilainya sesuai dengan domain halaman. Jika tidak, permintaan gagal.

Permintaan preflight menambahkan langkah-langkah berikut sebelum alur permintaan sederhana. Jika berhasil, proses dilanjutkan dengan cara yang sama seperti pada permintaan sederhana:

  1. Browser mengirim permintaan OPTIONS yang mencakup metode (Access-Control-Request-Method) dan header (Access-Control-Request-Headers) dari permintaan utama yang dimaksud.

  2. OSS memeriksa apakah metode dan header dalam permintaan diizinkan berdasarkan konfigurasi CORS. Jika permintaan preflight mencakup metode atau header yang tidak diizinkan oleh aturan, permintaan gagal dan permintaan utama tidak dikirim.

Muat sumber daya website statis

Website di https://www.example.com perlu memuat file gambar, CSS, dan JS yang disimpan di bucket OSS.

Langkah 1: Konfigurasikan aturan CORS

Login ke OSS console. Buka halaman Content Security > CORS untuk bucket tujuan dan buat aturan sebagai berikut:

Parameter

Nilai

Deskripsi

Origin

https://www.example.com

Membatasi akses hanya untuk website ini.

Allowed Methods

GET, HEAD

GET mengunduh sumber daya; HEAD memvalidasi cache.

Allowed Headers

Kosong

Tidak diperlukan — permintaan simple tidak memicu preflight.

Exposed Headers

ETag, Content-Length

  • ETag memungkinkan browser memvalidasi cache dengan permintaan HEAD. Jika objek tidak berubah, server mengembalikan respons 304 Not Modified untuk mencegah pengunduhan ulang.

  • Content-Length dapat digunakan untuk menampilkan progres pemuatan sumber daya di antarmuka depan.

Cached Timeout (Seconds)

86400

Menyimpan hasil preflight dalam cache selama 24 jam.

Vary: Origin

Tidak dicentang

Tidak diperlukan untuk satu asal spesifik.

Langkah 2: Verifikasi konfigurasi

Buka https://www.example.com dan pastikan sumber daya OSS, seperti gambar, dimuat dengan benar serta tidak ada error CORS di konsol browser.

Unggah file langsung dari antarmuka depan

Pengguna di halaman web https://app.example.com mengunggah file, seperti avatar dan dokumen, langsung ke OSS.

Langkah 1: Konfigurasikan aturan CORS

Login ke OSS console. Buka halaman Content Security > CORS untuk bucket tujuan dan buat aturan sebagai berikut:

Parameter

Nilai

Deskripsi

Origin

https://app.example.com

Membatasi unggahan hanya untuk aplikasi resmi ini.

Allowed Methods

PUT, POST

PUT atau POST diperlukan untuk unggahan.

Allowed Headers

*

Unggahan langsung menggunakan tanda tangan sementara (presigned URLs) alih-alih header Authorization tetap demi keamanan. * mengakomodasi berbagai header SDK (misalnya, x-oss-meta-*) tanpa menimbulkan risiko.

Exposed Headers

ETag, x-oss-request-id

  • ETag: Pengenal unik untuk unggahan file yang berhasil, digunakan untuk verifikasi selanjutnya.

  • x-oss-request-id: Digunakan untuk troubleshooting unggahan yang gagal.

Cached Timeout (Seconds)

600

Cache 10 menit menyeimbangkan pengurangan preflight dengan pembaruan konfigurasi yang cepat.

Vary: Origin

Dicentang

Mencegah polusi cache CDN untuk penerapan multi-domain potensial.

Langkah 2: Verifikasi konfigurasi

Lakukan operasi unggah di halaman https://app.example.com dan pastikan file berhasil diunggah ke OSS serta tidak ada error CORS di konsol browser.

Dukungan untuk beberapa lingkungan

Beberapa subdomain untuk pengembangan, pengujian, dan produksi, seperti dev.example.com dan app.example.com, perlu mengakses sumber daya OSS yang sama.

Langkah 1: Konfigurasikan aturan CORS

Login ke OSS console. Buka halaman Content Security > CORS untuk bucket tujuan dan buat aturan sebagai berikut:

Parameter

Nilai

Deskripsi

Origin

https://*.example.com

Karakter wildcard * mengizinkan semua subdomain HTTPS di bawah example.com.

Allowed Methods

GET, PUT, POST

Mendukung pembacaan dan unggahan di semua lingkungan.

Allowed Headers

*

Karakter wildcard * menghindari perubahan aturan CORS yang sering saat lingkungan memperkenalkan header kustom berbeda.

Exposed Headers

ETag, x-oss-request-id

Mendukung validasi unduhan dan umpan balik hasil unggahan.

Cached Timeout (Seconds)

3600

Cache 1 jam menyeimbangkan performa dengan fleksibilitas debugging.

Vary: Origin

Dicentang

Wajib. Menginstruksikan CDN untuk menyimpan cache respons per Origin, mencegah konflik antarlingkungan.

Langkah 2: Verifikasi konfigurasi

Lakukan pengujian akses atau unggah di kedua halaman https://dev.example.com dan https://app.example.com untuk memastikan semua operasi berhasil.

Lakukan panggilan bergaya API dengan autentikasi

Aplikasi antarmuka depan di https://api.example.com perlu mengakses sumber daya OSS yang dilindungi dengan menyertakan header kustom seperti Authorization.

Langkah 1: Konfigurasikan aturan CORS

Login ke OSS console. Di bucket tujuan, buka halaman Content Security > CORS dan buat aturan sebagai berikut:

Parameter

Nilai

Deskripsi

Origin

https://api.example.com

Untuk permintaan dengan informasi autentikasi, origin harus berupa domain tepercaya yang tepat.

Allowed Methods

GET, PUT, DELETE

Mendukung pembacaan, pembaruan, dan penghapusan sumber daya privat.

Allowed Headers

authorization, content-type, x-oss-*

Jangan gunakan *. Cantumkan header yang diperlukan secara eksplisit (prinsip hak istimewa minimal).

Exposed Headers

ETag, x-oss-request-id

Memberikan pengenal verifikasi untuk operasi yang berhasil dan ID untuk troubleshooting.

Cached Timeout (Seconds)

600

Cache lebih pendek (10 menit) memastikan perubahan kebijakan keamanan diterapkan dengan cepat.

Vary: Origin

Pilih

Memastikan CDN menyimpan cache respons secara terpisah per origin.

Langkah 2: Verifikasi konfigurasi

Kirim permintaan dengan header Authorization dari halaman https://api.example.com dan pastikan Anda dapat mengakses sumber daya OSS yang dilindungi.

Terapkan di produksi

Praktik keamanan terbaik

Ikuti prinsip hak istimewa minimal.

  • Konfigurasikan Origin (AllowedOrigin) secara tepat: Hindari menetapkan * untuk Sources kecuali bucket Anda sepenuhnya publik. Tentukan domain eksplisit, seperti https://www.example.com.

  • Batasi Allowed Methods: Ekspos hanya metode HTTP yang dibutuhkan aplikasi Anda. Untuk situs read-only, konfigurasikan hanya GET dan HEAD.

  • Tentukan Allowed Headers secara eksplisit: Untuk permintaan terotentikasi (dengan header Authorization), jangan gunakan *. Cantumkan semua header permintaan yang diperlukan secara eksplisit.

Praktik performa terbaik

  • Optimalkan cache preflight: Nilai MaxAgeSeconds yang wajar, seperti 86400 detik (24 jam), secara signifikan mengurangi permintaan preflight, sehingga menurunkan latensi dan biaya.

  • Evaluasi dampak Vary: Origin: Mengaktifkan Vary: Origin menyelesaikan masalah cache poisoning tetapi meningkatkan kompleksitas caching CDN. Hal ini dapat menurunkan rasio hit cache dan meningkatkan lalu lintas kembali ke asal (biaya dan latensi tambahan). Aktifkan hanya setelah mengevaluasi pola lalu lintas Anda.

Akselerasi CDN

Jika bucket Anda diakselerasi oleh Alibaba Cloud CDN dan diakses melalui domain CDN, permintaan lintas asal akan pertama kali mencapai Titik Kehadiran (PoP) CDN. Anda harus mengonfigurasi aturan CORS di konsol CDN, bukan di konsol OSS. Konfigurasi CORS di OSS hanya berlaku untuk permintaan yang langsung ditujukan ke domain origin OSS. Untuk detailnya, lihat Konfigurasikan Berbagi Sumber Daya Lintas Asal.

Parameter aturan CORS

Anda dapat mengonfigurasi hingga 20 aturan CORS untuk setiap bucket. OSS mengevaluasi aturan secara berurutan dari atas ke bawah dan menerapkan aturan pertama yang sesuai dengan permintaan. Setelah ditemukan kecocokan, OSS tidak memeriksa aturan berikutnya.

Parameter

Wajib

Deskripsi

Origin (AllowedOrigin)

Ya

Menentukan website (domain asal) yang diizinkan membuat permintaan lintas asal ke sumber daya OSS.

  • Formatnya adalah protocol://domain atau alamat IP[:port]. Contoh: https://www.example.com atau http://192.168.1.1:8080.

  • Karakter wildcard * didukung, tetapi hanya dapat digunakan sekali dalam setiap origin.

    • Contoh valid: https://*.example.com, http://localhost:*, atau http://192.168.1.1:8080

    • Contoh tidak valid: https://*.example.* atau https://*

  • Beberapa origin diperbolehkan, satu per baris.

Allowed Methods (AllowedMethod)

Ya

Menentukan metode HTTP yang diizinkan.

  • Nilai valid: GET, PUT, POST, DELETE, HEAD.

  • Beberapa metode diperbolehkan.

Allowed Headers (AllowedHeader)

Tidak

Berlaku untuk permintaan preflight dan menentukan header HTTP mana yang dapat disertakan dalam permintaan aktual.

  • Karakter wildcard * didukung, yang mengizinkan semua header.

  • Beberapa header diperbolehkan, satu per baris. Header TIDAK case-insensitive.

Exposed Headers (ExposeHeader)

Tidak

Menentukan header respons OSS mana yang dapat diakses oleh JavaScript sisi klien.

  • Karakter wildcard * tidak didukung.

  • Beberapa header diperbolehkan, satu per baris.

  • Kasus penggunaan: Untuk mendapatkan ETag atau x-oss-request-id file yang diunggah dalam JavaScript, tambahkan ETag dan x-oss-request-id ke parameter ini.

Cached Timeout (MaxAgeSeconds)

Tidak

Menentukan waktu dalam detik yang dapat digunakan browser untuk menyimpan cache hasil permintaan preflight OPTIONS.

  • Efek: Selama durasi cache, permintaan lintas asal identik berikutnya untuk sumber daya yang sama tidak akan memicu permintaan preflight baru, sehingga mengoptimalkan performa.

Vary: Origin

Tidak

Menentukan apakah akan menambahkan header respons HTTP Vary: Origin. Header ini memberi tahu CDN dan cache perantara lainnya untuk menyimpan cache versi berbeda dari sumber daya berdasarkan header Origin permintaan. Hal ini mencegah polusi cache saat beberapa origin mengakses sumber daya yang sama.

  • Kasus penggunaan: Untuk mencegah polusi cache saat Anda mengonfigurasi beberapa domain atau wildcard untuk parameter Sources, aktifkan opsi ini.

Penting

Mengaktifkan opsi ini dapat menurunkan rasio hit cache CDN.

FAQ

Error: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Error ini biasanya berarti browser telah menyimpan cache respons lama tanpa header CORS, atau tidak ada aturan CORS yang sesuai dengan permintaan masuk.

Bersihkan cache browser Anda dan uji ulang. Jika error tetap muncul, verifikasi aturan CORS Anda:

  1. Login ke OSS console.

  2. Klik Buckets, lalu klik nama bucket tujuan.

  3. Di panel navigasi kiri, pilih Content Security > CORS.

  4. Di halaman CORS, klik Create Rule.

  5. Di panel Create CORS Rule, atur Origin ke *, pilih semua Allowed Methods, atur Allowed Headers ke *, atur Exposed Headers ke ETag dan x-oss-request-id, atur Cache Timeout (Seconds) ke 0, pilih Vary: Origin, lalu klik OK.

  6. Jika masalah tetap berlanjut, login ke server apa pun dan jalankan perintah berikut untuk melihat header permintaan lintas asal.

    curl -v -o output_file.txt -H 'Origin:[$URL2]' '[$URL1]'
    Catatan
    • [URL1] adalah URL sumber daya OSS yang diminta.

    • [URL2] adalah alamat origin yang Anda konfigurasikan dalam aturan CORS.

    Sistem menampilkan output yang mirip dengan berikut.

    • Jika respons menyertakan header CORS yang sesuai, kemungkinan besar masalahnya adalah cache browser atau jaringan. Permintaan non-CORS sebelumnya mungkin telah disimpan dalam cache lokal, dan permintaan lintas asal berikutnya mengambil respons cache ini alih-alih mendapatkan respons baru dari server. Coba solusi berikut:

      • Tekan Ctrl+F5 di browser Anda untuk membersihkan cache, lalu uji apakah masalah masih berlanjut.

      • Atur Cached-Seconds ke 0 dalam aturan CORS. Ini memaksa setiap permintaan untuk mengambil ulang otorisasi CORS dari server.

        Catatan

        Anda dapat mengatur cache-control objek ke no-cache saat mengunggahnya. Untuk objek yang sudah diunggah, Anda dapat menggunakan ossutil untuk mengubah pengaturan ini. Untuk informasi lebih lanjut, lihat set-meta (Kelola metadata objek).

      • Gunakan CDN untuk mengakselerasi OSS, memastikan semua permintaan yang dilayani CDN menyertakan header CORS.

    • Jika respons berisi dua header CORS atau header yang tidak sesuai dengan konfigurasi OSS Anda, kemungkinan besar masalah disebabkan oleh penggunaan CDN untuk mengakselerasi OSS:

      1. Login ke CDN console dan nonaktifkan sementara akselerasi CDN untuk nama domain guna memastikan masalah lintas asal terselesaikan.

      2. Setelah dikonfirmasi, klik nama domain tertentu, lalu buka Cache Configuration > Node HTTP Response Header.

      3. Atur header respons HTTP kustom sesuai kebutuhan.

  7. Jika masalah CORS masih belum terselesaikan, lihat Error umum dan solusi untuk CORS OSS untuk troubleshooting lebih lanjut.

Error: The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin.

Server mengembalikan header Access-Control-Allow-Origin, tetapi nilainya tidak sesuai dengan Origin permintaan. Hal ini sering kali merupakan masalah caching — browser atau CDN menyimpan cache respons untuk satu domain dan melayaninya ke domain lain.

Aktifkan opsi Vary: Origin dalam aturan CORS Anda untuk mencegah konflik cache antarwebsite berbeda, atau bersihkan cache browser Anda sebelum mencoba ulang.

Error: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

Error ini terjadi karena antarmuka depan mengirim permintaan ber-kredensial (Access-Control-Allow-Credentials adalah True), tetapi Access-Control-Allow-Origin diatur ke *. Browser melarang kombinasi ini untuk mencegah situs mana pun mengakses data sensitif seperti cookie atau token Authorization.

  • Jika Anda memerlukan kredensial, ubah Sources dari * menjadi domain spesifik (misalnya, https://example.com).

  • Jika Anda tidak memerlukan kredensial, atur xhr.withCredentials ke false dalam kode antarmuka depan Anda dan pastikan Access-Control-Allow-Credentials adalah false di server.

Bagaimana cara memperbaiki pemuatan lintas asal dari OSS yang lambat?

Kecepatan pemuatan lintas asal bergantung pada latensi jaringan antara klien dan bucket OSS. Permintaan lintas asal menyertakan header Origin. Untuk akses jarak jauh (misalnya, China (Hong Kong) ke daratan Tiongkok), gunakan titik akhir Transfer Acceleration untuk mengoptimalkan jalur jaringan.

Catatan

Transfer Acceleration mengoptimalkan jalur jaringan untuk meningkatkan kecepatan transfer data global.