CORS

CORS (Cross-Origin Resource Sharing), bir kaynaktan gelen JavaScript’in başka bir kaynaktan gelen yanıtları ne zaman okuyabileceğini denetleyen tarayıcı mekanizmasıdır. Tarayıcılar varsayılan olarak çapraz kaynaklı XHR/fetch yanıtlarını engeller — sunucudan gelen CORS başlıkları kontrollü erişimi açar.

İki ana yanıt başlığı:

• Access-Control-Allow-Origin: yanıtı hangi kaynakların okuyabileceği. Belirli bir kaynak ya da * (herhangi bir).
• Access-Control-Allow-Credentials: çerezlerin çapraz kaynaklı isteklerle birlikte akmasına izin verilip verilmeyeceği. true, kaynağın * değil, belirli olmasını gerektirir.

“Basit” olmayan istekler (özel başlıklar, GET/POST dışı yöntemler, JSON gövdeleri) için tarayıcı önce neye izin verildiğini kontrol etmek amacıyla bir ön uçuş OPTIONS isteği gönderir. Sunucu, Access-Control-Allow-Methods ve Access-Control-Allow-Headers ile yanıt verir; gerçek istek yalnızca ön uçuş başarılı olursa gönderilir.

Yaygın yanlış anlamalar: CORS bir sunucu tarafı güvenlik mekanizması değildir — kullanıcıları bir sitenin başka bir site adına veri okumasından koruyan tarayıcı tarafından uygulanan bir kısıtlamadır. Sunucular çapraz kaynaklı istekleri almaya ve işlemeye devam edebilir; CORS yalnızca tarayıcının yanıtı çağıran JavaScript’e iletip iletmeyeceğini denetler.

“Kaynak” tam olarak ne anlama gelir: (şema, host, port) üçlüsü. http://example.com ve https://example.com farklı kaynaklardır (farklı şema). https://api.example.com ve https://example.com farklı kaynaklardır (farklı alt alan). https://example.com:8080 ve https://example.com farklı kaynaklardır (farklı port). Bu, CORS’un üzerine istisnalar eklediği aynı kaynak politikasıdır. Internet Explorer port bölümünü görmezden gelirdi — IE’nin kullanımdan kalkmasına kadar yıllarca çapraz tarayıcı hatalarına yol açan bir tuhaflık.

Yaygın üretim tuzakları: joker karakter Access-Control-Allow-Origin: *, spesifikasyon gereği kimlik bilgilerini engeller; çapraz kaynaklı bir istekte çerezlere ihtiyacınız varsa isteğin Origin’ini özellikle geri yansıtmalısınız. Authorization başlığı eklemek, isteği “basit”ten “ön uçuşlu”ya yükseltir ve tur-trip sayısını iki katına çıkarır — Access-Control-Max-Age aracılığıyla ön uçuşu önbelleğe almak (Chrome’da 7200 saniyeye, Firefox’ta 600’e kadar) standart çözümdür. Son olarak, DevTools konsolundaki tarayıcının CORS hatası gerçekten tarayıcının kararıdır — sunucu günlükleri isteğin arka uca ulaştığını ve normal şekilde işlendiğini gösterir; yanıt yalnızca istemci tarafında atılmıştır. Başvuru: WHATWG Fetch — HTTP-CORS Protokolü.

Çalışma örneği: ön uçuşlu bir JSON POST

https://app.example.com adresindeki bir SPA, taşıyıcı token ile https://api.example.com/v1/orders adresine JSON POST’lar. İstek Content-Type: application/json ve Authorization başlığı kullandığından basit değildir. Tarayıcı önce Origin: https://app.example.com, Access-Control-Request-Method: POST ve Access-Control-Request-Headers: authorization,content-type ile OPTIONS /v1/orders gönderir. Sunucu Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Methods: POST, Access-Control-Allow-Headers: authorization,content-type ve Access-Control-Max-Age: 600 ile 204 yanıt verir. Ancak o zaman gerçek POST tetiklenir. Max-Age: 600 ayarı, sonraki 10 dakika boyunca ön uçuştan kaçınır ve her sonraki çağrıdan bir tur-trip elimine eder — transatlantik bağlantılarda 50-100 ms azalma olarak ölçülebilir.

CORS’un yetmediği durumlar

CORS, kullanıcıları çapraz kaynaklı okumalardan korur; sunucuları istenmeyen isteklerden korumaz. Durum değiştiren uç noktalar hâlâ CSRF token’larına veya SameSite çerezlerine ihtiyaç duyar ve kimlik doğrulama, sunucu tarafında uygun token doğrulaması gerektirir. Access-Control-Allow-Origin: * arkasındaki bir genel API, herkes tarafından çağrılabilir — CORS yalnızca tarayıcının bu gerçeği yüzeye çıkarmasını sağlamıştır. Daha derin mimari arka plan için pratik örneklerle WHATWG spec’i yansıtan MDN’in CORS referansına bakın.