CORS Güvenlik: Farklı İmplementasyon Yaklaşımlarının Karşılaştırması

Web uygulamalarında ön uç ve arka uç arasındaki iletişim, modern yazılım geliştirmenin temel taşıdır. Ancak bu iletişim sırasında güvenlik sorunları ortaya çıkabilir. CORS (Cross-Origin Resource Sharing), tarayıcılar tarafından uygulanan bir güvenlik mekanizması olup, farklı kaynaklardan gelen isteklerin kontrolünü sağlar. Doğru CORS konfigürasyonu yapmak, uygulamanızın güvenliğini korurken aynı zamanda işlevselliğini de korumanız anlamına gelir. Bu rehberde, CORS cross-origin güvenlik için kullanılan temel yaklaşımları yan yana koyarak, her birinin artı ve eksilerini analiz edeceğiz.

1. Tamamen Açık CORS Yapılandırması vs. Katı Kontrol

CORS güvenlik stratejisinin en temel ayrımı, ne kadar açık olduğunuzdur.

Tamamen Açık Yaklaşım: Bazı geliştiriciler, hızlı prototipleme aşamasında tüm kaynaklara izin vermek için wildcard (*) kullanırlar. Bu yapılandırma:

Geliştirme sürecini hızlandırır
İnitiyatif almayı kolaylaştırır, ancak
Üretim ortamında ciddi güvenlik riskleri oluşturur
CSRF (Cross-Site Request Forgery) saldırılarına açık hale getirir

Katı Kontrol Yaklaşımı: Her izin verilen kaynağı açıkça tanımlamak (whitelist yöntemi):

Hangi domain'lerin erişebileceğini tam olarak kontrol edersiniz
Ek yönetim yükü getirir ancak maksimum güvenlik sağlar
Üretim ortamında standart uygulamadır
Başlangıçta daha fazla yapılandırma gerektirir

Karar kriterleri: Geliştirme ortamında açık CORS kullanabilirsiniz, ancak üretim için mutlaka whitelist oluşturmalısınız. Bu, bilinen ve güvenilir kaynakların belirtilmesi anlamına gelir.

2. Basit İstekler vs. Preflight Mekanizması

CORS, istekleri iki kategoriye böler. Bu ayrım, CORS cross-origin işlemlerinin karmaşıklığını anlama açısından kritiktir.

Basit İstekler: GET, HEAD veya POST istekleri (belirli header koşullarıyla):

Tarayıcı doğrudan isteği gönderir
Preflight kontrolü gerekmez, performans açısından hızlıdır
Limited functionality sunar
Daha az kontrol mekanizması vardır

Preflight Mekanizması: DELETE, PUT veya özel header'lar içeren istekler:

Tarayıcı ilk olarak OPTIONS isteği gönderir
Sunucu izin verirse, asıl istek gönderilir
Ekstra ağ trafiği yaratır (iki istek yerine bir istek gerekmez)
Daha kapsamlı güvenlik kontrolü imkanı sunar
Karmaşık operasyonlar için vazgeçilmezdir

Karşılaştırmada dikkat edilmesi gereken nokta: Basit istekler performans açısından avantajlı görünse de, gerçek dünya uygulamalarında preflight mekanizması tarafından sağlanan kontrol, bu küçük performans kaybını haklı çıkarır.

3. Backend vs. Frontend Çözümleri

CORS problemlerine iki ana perspektiften yaklaşılabilir. Her perspektifin felsefesi ve uygulanabilirliği farklıdır.

Backend Çözümleri: Sunucu tarafından CORS header'larının ayarlanması:

Access-Control-Allow-Origin, Access-Control-Allow-Methods gibi header'ları tanımlamak
Tam kontrol ve güvenlik sağlar—sunucu kaynakları korumalı kalır
Proxy sunucular veya API gateway'ler aracılığıyla yönetilir
Tüm istemcilere (web, mobil, masaüstü) uygulanır
Güvenlik açısından tavsiye edilen yöntemdir

Frontend Çözümleri: Proxy sunucusu veya JSONP gibi alternatifler:

Frontend'de bir proxy katmanı oluşturulur
CORS problemini kısa vadeli olarak çözer, ancak mimariye ek katman ekler
Üretim için güvenlik açısından zayıftır
Geliştirme/test aşamasında yararlıdır

4. Kimlik Doğrulama ile CORS Entegrasyonu

CORS güvenlik stratejisi, kimlik doğrulama mekanizmalarıyla birlikte ele alınmalıdır.

Credentials Dahil Yaklaşım: Cookies veya Authorization header'larını göndermek:

Oturum bilgilerini cross-origin isteklerde korumanız gerektiğinde kullanılır
Access-Control-Allow-Credentials: true gerektirir
Wildcard (*) kullanılamaz—kesin kaynaklar belirtilmesi zorunlu
Token tabanlı kimlik doğrulamaya (JWT) uygun

Credentials Hariç Yaklaşım: Kimlik doğrulama bilgisi göndermedikleri istekler:

Herkese açık API'ler için yeterlidir
Daha az güvenlik riski taşır
Performans açısından biraz daha hafiftir

Karşılaştırma sonucu: Eğer uygulamanız kullanıcı oturumuna bağlı ise, credentials dahil yaklaşımı seçmek ve whitelist yöntemi uygulamak zorunludur.

Özet Karşılaştırma Tablosu

Yaklaşım	Güvenlik Seviyesi	Performans	Komplekslik	Kullanım Alanı
Wildcard CORS	Düşük	Yüksek	Çok Düşük	Geliştirme Ortamı
Whitelist Yöntemi	Yüksek	Yüksek	Orta	Üretim Ortamı
Basit İstekler	Orta	Yüksek	Düşük	Basit API'ler
Preflight Kontrolü	Yüksek	Orta	Orta	Kompleks İşlemler
Backend Yönetimi	Yüksek	Yüksek	Orta	Tüm Üretim Sistemleri
Frontend Proxy	Düşük	Orta	Düşük	Geliştirme/Test

Sonuç: Doğru CORS Stratejisini Seçmek

CORS cross-origin güvenlik konusunda "tek doğru yol" yoktur; seçim, uygulamanızın gereksinimlerine bağlıdır. Ancak temel ilke net: geliştirme ortamında hızlı ilerlemek için açık CORS kullanabilirsiniz, ama üretim ortamında kesinlikle whitelist tabanlı, backend'de yönetilen, kimlik doğrulama ile entegre bir çözüm uygulamalısınız.

Başlangıç aşamasında basit istekleri tercih edebilirsiniz, ancak uygulamanız büyüdükçe preflight mekanizmasının sağladığı ek kontrol seviyesine ihtiyaç duyacaksınız. Kimlik doğrulama gerektiren uygulamalarda ise, credentials dahil yaklaşım ve strict origin kontrolü kombinasyonu, hem güvenliği hem de işlevselliği en iyi şekilde dengeleyecektir. Seçiminizi yaparken, sadece immediate gereksinimler değil, uzun vadeli güvenlik ve bakım gereksinimlerini de göz önünde bulundurun.