CORS Yanlış Yapılandırması: Kökeni Herkese Açmanın Sessiz Riski

CORS (Cross-Origin Resource Sharing), tarayıcının bir web sayfasının başka bir kaynaktan (origin) veri okumasına ne zaman izin verileceğini belirleyen bir mekanizmadır. Sık karıştırılan nokta şudur: CORS bir saldırı değil, tarayıcının Same-Origin Policy kısıtını gevşetme yöntemidir. Yanlış yapılandırıldığında, koruması gereken veriyi başka sitelere açar. Bu yazıda CORS’un ne işe yaradığını, en tehlikeli yanlış yapılandırmayı ve güvenli kuralları örneklerle görüyoruz.

Önce Same-Origin Policy

Tarayıcılar varsayılan olarak bir sayfanın, farklı bir kaynağın yanıtını JavaScript ile okumasını engeller (Same-Origin Policy). “Kaynak” = şema + alan adı + port. Yani https://siteniz.com üzerindeki bir sayfa, https://banka.example’ın API yanıtını okuyamaz. Bu, kötü niyetli bir sitenin sizin adınıza API’nizden veri çekip okumasını engelleyen temel güvenlik sınırıdır.

CORS, bu sınırı bilinçli olarak gevşetmenin standart yoludur: API’niz, “şu kaynaktan gelen isteklerin yanıtımı okumasına izin veriyorum” der. Bunu Access-Control-Allow-Origin başlığıyla yapar.

En tehlikeli hata: köken yansıtma + credentials

En kritik yanlış yapılandırma, kimlik doğrulamalı (cookie/token ile) bir API’de kökeni doğrulamadan yansıtmaktır. Bazı sunucular, gelen Origin başlığını olduğu gibi geri yazar:

Access-Control-Allow-Origin: https://saldirgan.example
Access-Control-Allow-Credentials: true

Burada sunucu, hangi köken gelirse onu izinli ilan ediyor ve credentials’a izin veriyor. Sonuç: kötü niyetli bir site, kurbanın oturumuyla API’nizden kimliği doğrulanmış veri okuyabilir. Spesifikasyon Access-Control-Allow-Origin: * ile Allow-Credentials: true birlikte kullanımına izin vermez; saldırının çalıştığı yer tam da kökenin yansıtıldığı bu durumdur.

Wildcard’ın kendisi (Access-Control-Allow-Origin: *) halka açık, kimlik gerektirmeyen bir uç nokta için sorun değildir; asıl tehlike, kimlik doğrulamalı veride köken yansıtmadır.

Güvenli yapılandırma ilkeleri

1. Kökenleri allowlist ile doğrulayın. Gelen Origin’i sabit bir izinli liste ile karşılaştırın; eşleşiyorsa o spesifik kökeni yansıtın, değilse başlığı hiç göndermeyin.
2. Allow-Credentials: true’yu yalnız gerçekten gerekliyse ve asla wildcard/yansıtılmış kökenle birleştirmeyin.
3. Yalnız gereken metot ve başlıkları açın (Access-Control-Allow-Methods, Access-Control-Allow-Headers); “hepsi” demeyin.
4. null kökenine güvenmeyin. Bazı bağlamlar (sandbox iframe, dosya) Origin: null gönderir; bunu izinli listeye koymak atlatılabilir.

Nasıl test edilir?

Bir uç noktanın köken yansıtıp yansıtmadığını basitçe deneyebilirsiniz: isteğe uydurma bir Origin başlığı ekleyip yanıtı inceleyin.

curl -sI -H "Origin: https://rastgele-saldirgan.example" https://api.siteniz.com/veri \
  | grep -i access-control-allow

Yanıtta access-control-allow-origin: https://rastgele-saldirgan.example ve özellikle access-control-allow-credentials: true görüyorsanız, uç nokta güvenli değildir; köken doğrulanmadan yansıtılıyor demektir.

CORS neyi KORUMAZ?

CORS bir yetkilendirme katmanı değildir. Yanıtın okunmasını kısıtlar ama isteğin sunucuya ulaşmasını engellemez. Yani sunucu tarafı yetkilendirme (kim ne yapabilir) hâlâ zorunludur; CORS onun yerine geçmez. Ayrıca CORS, CSRF’yi tek başına çözmez.

Özet

CORS’u “veriyi hangi sitelerin okuyabileceğini” belirleyen bir kapı olarak düşünün. Kapıyı herkese (*) açmak halka açık veride sorun değil, ama kimlik doğrulamalı API’de köken yansıtma + credentials ölümcül bir kombinasyondur. Güvenli kural: kökenleri allowlist ile doğrula, credentials’ı ölçülü ver, wildcard’ı yalnız kimliksiz uç noktalarda kullan. Bir curl denemesiyle uç noktanızı hemen test edebilirsiniz.

Kaynaklar: MDN: CORS, PortSwigger: CORS, OWASP CORS.

API’nizin CORS başlıklarının güvenli olup olmadığını merak ediyor musunuz? CyberTestify’ın dış yüzey taraması yaygın CORS yanlış yapılandırmalarını yakaladığı gerçek yanıtlardan tespit eder.