CORS cross-origin güvenlik seçerken nelere dikkat edilmeli

CORS Cross-Origin Güvenlik: Seçim Yaparken Nelere Dikkat Edilmeli?

Web uygulamalarını geliştiren kurumlar ve yazılım ekipleri, farklı kaynaklardan veri alışverişi yaparken güvenlik sorunuyla karşı karşıya gelirler. CORS (Cross-Origin Resource Sharing) cross-origin güvenlik, bu veri alışverişini kontrol etmek için tasarlanmış bir mekanizmadır. Ancak CORS'u uygulamak basit görünse de, yanlış konfigürasyon ciddi açıklıklara neden olabilir. Bu rehber, CORS cross-origin güvenlik seçeneklerini değerlendirirken hangi kriterleri göz önüne almanız gerektiğini detaylı bir şekilde inceliyor.

CORS'un Temel İşleyişini Anlamak

CORS, tarayıcı güvenliğinin bir parçası olan Same-Origin Policy kuralını kırmak için gerekli bir araçtır. Eğer bir web sitesi başka bir domaindan veri istemek istiyorsa, sunucu tarafından açık izin verilmesi gerekir. Bu izin, HTTP başlıkları aracılığıyla iletilir.

CORS cross-origin güvenlik seçeneğini belirlerken ilk adım, hangi kaynakların (origins) erişim alması gerektiğini saptamaktır. "Tüm kaynakları aç" demek (*) veya belirli domainleri listeleme arasında büyük fark vardır. Örneğin, genel API sunan bir hizmet ile sadece kendi ön yüzünü besleyen bir sunucu tamamen farklı CORS politikaları gerektirir.

Genel API'ler: Daha esnek CORS ayarları, ancak sınırlamalar gerekli
İç kullanım API'leri: Daha katı ve spesifik konfigürasyonlar ideal
Üçüncü taraf entegrasyonlar: Değişken gereksinimler ve düzenli güncelleme

Erişim İzin Verilen Kaynakları Tanımlama

CORS cross-origin güvenlik politikasının en kritik bileşeni, hangi web sitelerinin API'nize erişebileceğini belirlemektir. Bu konuda üç ana yaklaşım bulunur:

Yaklaşım 1: Joker (Wildcard) İzin - Tüm kaynaklar (*) erişime açık hale getirilir. Bu, geliştirme aşamasında hızlı test etmek için uygun olsa da, üretim ortamında tehlikelidir. İstismarçılar herhangi bir yerden API'nizi çağırabilir.

Yaklaşım 2: Spesifik Domain Listesi - Yalnızca https://yourapp.com ve https://partner.com gibi belirli domaınlar erişime izin verilir. Bu, en güvenli ve önerilen yöntemdir. Her yeni partner eklendikçe liste güncellenir.

Yaklaşım 3: Dinamik Doğrulama - Gelen istek kaynağı veri tabanında kontrol edilir. Daha esnek ama işlem yoğun bir çözümdür.

Wildcard (*): Hızlı ama riskli, geliştirme için uygun
Whitelist: Güvenli ve kontrollü, üretim ortamında standart
Dinamik kontrol: Esnek ama performans maliyeti olabilir

Kimlik Doğrulama ve Credential Yönetimi

CORS cross-origin güvenlik söz konusu olduğunda, sadece hangi sitelerin erişebileceği değil, hangi bilgilerin taşınacağı da önemlidir. Credentials (çerezler, HTTP kimlik doğrulama) cross-origin istekleriyle beraber gönderilip gönderilmeyeceğinin belirlenmesi gerekir.

Credentials ile çalışmak daha katı kurallar gerektirir. Wildcard (*) başlığı kullanıyorsanız, credentials desteklenemez. Bunu etkinleştirirken, istek kaynakları açıkça listelenmeli ve `Access-Control-Allow-Credentials: true` başlığı gönderilmelidir. Bu kombinasyon, yetkisiz erişime karşı sağlam bir engel oluşturur.

Ayrıca, gönderilen ve alınan HTTP yöntemlerine (GET, POST, PUT, DELETE) sınırlamalar getirilmelidir. Bir halkla açık API'nin POST ve DELETE yöntemlerine tüm kaynaklardan izin vermesi, veri bütünlüğü için ciddi risk taşır.

Preflight İsteklerini ve Cache Sürelerini Kontrol Etmek

Karmaşık CORS istekleri, tarayıcı tarafından ön kontrol (preflight) istekleri ile doğrulanır. Bu, OPTIONS metodu kullanarak yapılan ek bir istek demektir. Preflight mekanizması güvenlik için yararlı olsa da, performansı etkiler.

CORS cross-origin güvenlik stratejinizde, preflight isteklerinin cache süresini ayarlayabilirsiniz. `Access-Control-Max-Age` başlığı, tarayıcının aynı endpoint için ne kadar süre preflight kontrol yapmayacağını belirler. 3600 saniye (1 saat) ile 86400 saniye (1 gün) arasında uygun değerler tutulur. Çok uzun setting, yeni güvenlik politikalarını geç uygulatır; çok kısa setting, gereksiz preflight trafiği oluşturur.

Cache süresi kısa (< 1 saat): Her istek kontrol edilir, daha güvenli
Cache süresi orta (1-6 saat): Denge sağlar, çoğu durumda uygun
Cache süresi uzun (> 12 saat): Performans artsa da, güvenlik riskleri

Ayrıca, izin verilen başlıklar (headers) ve expose edilen başlıklar (headers ön yüze açık) minimize edilmelidir. Hassas bilgiler içeren başlıkları asla expose etmeyin.

Düzenli Denetim ve Güncelleme

CORS cross-origin güvenlik, bir kez ayarlandıktan sonra unutulmaması gereken bir konfigürasyondur. İş ortağılıkları değişir, yeni platformlar entegre edilir ve tehditler evrimleşir. Altı aylık aralıklarla CORS politikanızı gözden geçirin. Hangi kaynaklar hala aktif erişim alıyor? Kullanılmayan kaynakları whitelist'ten çıkarın.

Loglama ve izleme de önemlidir. CORS hataları sık sık sessizce başarısız olur. Uygun logging sistemleriyle, başarısız preflight isteklerini ve şüpheli kaynakları takip edin. Bu, olası saldırıları erken tespit etmeye yardımcı olur.

Unutmayın: CORS, tarayıcı tarafında çalışan bir güvenlik mekanizmasıdır. Sunucu tarafında ek kimlik doğrulama ve yetkilendirme katmanları mutlaka olmalıdır.

CORS cross-origin güvenlik seçeneklerini değerlendirirken, işletmenizin ihtiyaçlarıyla güvenlik gereksinimlerini dengelemek kritiktir. Açık erişim hızlı entegrasyonlar sağlarken, katı sınırlamalar uygulamanızı korur. Doğru approach, teknoloji yığınınıza ve veri duyarlılığınıza bağlı olarak değişir. Yan yana karşılaştırma yaparak, kurumunuza en uygun CORS politikasını belirleyebilirsiniz.