CORS Güvenli Yapılandırma Rehberi

Tarayıcılar varsayılan olarak Aynı Köken Politikası'nı (Same-Origin Policy - SOP) uygular; bu politika, bir kökendeki JavaScript'in (örn. https://app.example.com) farklı bir kökenden (örn. https://api.example.com) gelen yanıtları okumasını engeller. CORS, tarayıcılara hangi çapraz kaynak isteklerine izin verildiğini bildirerek bu kısıtlamayı seçici olarak gevşeten mekanizmadır. CORS'u yanlış yapılandırırsanız, uygulamanızın her kullanıcısı için SOP'ta delikler açmış olursunuz.

• CORS başlıklarının tarayıcılar tarafından kullanıldığını anlayın — sunucudan sunucuya veya curl tabanlı istekleri korumaz.
• Basit istekler (temel içerik türleriyle GET, POST) ile ön uçuş (preflight) gerektiren istekler (karmaşık metotlar veya başlıklar için OPTIONS preflight) arasındaki farkı bilin.
• Geniş bir CORS politikasının Access-Control-Allow-Credentials: true ile birleştirildiğinde, bir saldırganın sitesinin kullanıcılarınız adına kimlik doğrulamalı yanıtları okuyabileceğini kavrayın.
• Hassas veya kimlik doğrulamalı veri döndüren her uç noktayı haritalandırın — bunlar en katı CORS kurallarını gerektirir.

CORS yapılandırmasındaki en kritik karar, hangi kaynakların güvenilir olduğuna karar vermektir. Joker karakter (*), herhangi bir web sitesinin yanıtı okuyabileceğini tarayıcıya bildirir; bu yalnızca kullanıcıya özgü veri içermeyen tam anlamıyla genel ve kimlik doğrulamasız kaynaklar (açık CDN varlıkları veya herkese açık API'lar) için kabul edilebilir.

• Kimlik doğrulama gerektiren veya kişiselleştirilmiş veri döndüren uç noktalarda asla Access-Control-Allow-Origin: * kullanmayın.
• Sunucu tarafında izin verilen kaynakların bir listesini tutun (örn. https://app.example.com, https://admin.example.com).
• Çapraz kaynak isteğine yanıt verirken, gelen Origin başlığını izin listenizle dinamik olarak karşılaştırın ve tam olarak eşleşen kaynağı yansıtın — keyfi kaynakları yansıtmayın.
• İzin listenize yalnızca üretim kaynaklarını ekleyin; geliştirme/hazırlık kaynaklarını ortama özgü yapılandırmayla yönetin, asla üretim koduna dahil etmeyin.
• Alt alan adlarını ayrı kaynaklar olarak değerlendirin — https://evil.example.com, https://app.example.com'dan farklıdır; tüm alt alan adlarını tam olarak kontrol etmiyorsanız *.example.com gibi geniş joker karakterler kullanmayın.

Access-Control-Allow-Methods başlığı, çapraz kaynak isteklerinde hangi HTTP metotlarına izin verildiğini tarayıcıya bildirir. Her metodu listelemek gereksiz yere saldırı yüzeyini artırır.

• Yalnızca API'nizin gerçekten ihtiyaç duyduğu metotları ekleyin — örneğin kapsamlı bir GET, POST, PUT, PATCH, DELETE, OPTIONS yerine GET, POST, PUT.
• TRACE ve CONNECT'i tamamen kaldırın; bunlar nadiren gereklidir ve belirli saldırı türlerine yardımcı olabilir.
• Uygulama çerçevenizin veya ters proxy'nizin bilginiz dışında otomatik olarak izin verici metot listeleri eklemediğini doğrulayın.

İki ayrı başlık, çapraz kaynak isteklerinin hangi başlıkları taşıyabileceğini ve JavaScript'in hangi yanıt başlıklarını okuyabileceğini yönetir. Her ikisi de mümkün olduğunca kısıtlayıcı olmalıdır.

• Access-Control-Allow-Headers'ı yalnızca API'nizin gelen isteklerden gerçekten okuduğu başlıklarla sınırlayın (örn. Content-Type, Authorization, X-Requested-With).
• Gelen Access-Control-Request-Headers değerini doğrulama yapmadan doğrudan geri yansıtmayın — bu, istemcilerin keyfi başlıklar enjekte etmesine izin verebilir.
• Access-Control-Expose-Headers'ı tutumlu kullanın; yalnızca istemci taraflı JavaScript'in gerçekten okumaya ihtiyaç duyduğu hassas olmayan özel başlıkları açığa çıkarın (örn. X-Request-ID).
• Token, oturum tanımlayıcısı veya dahili yönlendirme bilgisi içeren başlıkları asla açığa çıkarmayın.

Access-Control-Allow-Credentials: true ayarı, tarayıcıya çapraz kaynak isteklerine çerezleri, HTTP kimlik doğrulamasını ve TLS istemci sertifikalarını dahil etmesini ve yanıtı JavaScript'e açmasını bildirir. Bu kombinasyon, herhangi bir CORS yanlış yapılandırmasının riskini önemli ölçüde artırır.

• Access-Control-Allow-Credentials: true'yu yalnızca uygulamanızın gerçekten gerektirdiği durumlarda ayarlayın (örn. belirli bir güvenilir ön uç tarafından kullanılan oturum çerezi ile kimlik doğrulamalı API'lar).
• Kimlik bilgileri etkinleştirildiğinde, açık bir kaynak belirtmeniz zorunludur — kaynak * ise tarayıcı Access-Control-Allow-Credentials: true'yu yok sayar ve birçok çerçeve yanlışlıkla geniş açık bir politikaya geri döner.
• Çerez özelliklerini CORS ile birlikte denetleyin: CORS yanlış yapılandırılmış olsa bile savunma derinliği eklemek için SameSite=Strict veya SameSite=Lax, Secure ve HttpOnly kullanın.
• Bir uç nokta kimlik bilgisi gerektirmiyorsa, Access-Control-Allow-Credentials'ın atlanmış veya false olarak ayarlanmış olduğundan emin olun.

Preflight gerektiren istekler için tarayıcılar, gerçek istekten önce bir OPTIONS isteği gönderir. Access-Control-Max-Age başlığı, tarayıcıya preflight yanıtını kaç saniye önbelleğe alabileceğini bildirir; bu gecikmeyi azaltır. Bu değeri çok yüksek ayarlamak, yapılandırmanızı sıkılaştırdıktan sonra bile tarayıcıların eski veya izin verici bir politikayı önbellekte tutmasına neden olur.

• Access-Control-Max-Age'i makul bir değere ayarlayın — politikanızın ne sıklıkla değiştiğine bağlı olarak genellikle 300 (5 dakika) ile 7200 (2 saat) arasında.
• 86400'den (24 saat) yüksek değerlerden kaçının; çoğu tarayıcı değeri zaten sınırlar, ancak gereksiz uzun önbellekleme politika güncellemelerini geciktirir.
• Aktif geliştirme veya politika değişiklikleri sırasında tarayıcıları yeniden doğrulamaya zorlamak için Max-Age'i geçici olarak düşürün.

CORS'un tarayıcı tarafından uygulanması, istemci taraflı bir kontroldür. Curl, script'ler veya değiştirilmiş tarayıcılar kullanan kötü niyetli kişiler bunu tamamen atlayabilir ve API'nıza doğrudan erişebilir. CORS, kimlik doğrulamanın, yetkilendirmenin veya girdi doğrulamanın yerini almaz — bunları tamamlar.

• CORS politikasından bağımsız olarak tüm hassas uç noktalarda uygun kimlik doğrulama uygulayın (örn. Bearer token'ları, imzalı JWT'ler, oturum doğrulaması).
• Sunucu taraflı kaynak doğrulaması uygulayın: Origin başlığını ayrıştırın, izin listenizle karşılaştırın ve beklenmedik kaynaklardan gelen istekleri reddedin veya günlüğe kaydedin.
• Referer veya Origin başlıklarına tek erişim kontrol mekanizması olarak güvenmeyin — tarayıcı dışı bağlamlarda taklit edilebilirler.
• API'nıza CORS mantığından bağımsız olarak hız sınırlaması ve anomali tespiti uygulayın.
• Ters proxy'nizin (Nginx, Apache, Caddy, vb.) uygulama düzeyindeki politikanızı geçersiz kılan kendi izin verici CORS başlıklarını eklemediğinden emin olun.

CORS yanlış yapılandırmaları son derece kolay ortaya çıkar ve yalnızca kod incelemesiyle fark etmek zordur. Sistematik test — hem manuel hem de otomatik — sorunları saldırganlardan önce yakalamak için elzemdir. Sensagraph, web uygulamanızı aşırı izin verici kaynaklar, kimlik bilgisi açığı ve kimlik doğrulamalı uç noktalardaki joker karakter politikaları dahil olmak üzere CORS yanlış yapılandırmaları için sürekli tarar.

• Hazırlanmış Origin başlıklarıyla (örn. güvenilmeyen bir alan adı) çapraz kaynak istekleri göndererek ve sunucunuzun bunları geri yansıtmadığından emin olmak için yanıt başlıklarını inceleyerek manuel test yapın.
• Dinamik izin listesi mantığınızın doğru çalıştığını onaylamak için hem eşleşen güvenilir bir kaynak hem de eşleşmeyen bir kaynak ile test yapın.
• Kimlik bilgili istekleri açıkça test edin — güvenilmeyen bir kaynaktan withCredentials: true ile istek gönderin ve tarayıcının yanıtı engellediğini doğrulayın.
• Her uç nokta için doğru başlık değerlerini belirten entegrasyon testleri kullanarak CI/CD pipeline'ınıza CORS başlık doğrulamasını ekleyin.
• Bilinmeyen kaynaklardan gelen beklenmedik OPTIONS preflight isteklerini sunucu ve proxy günlüklerinde izleyin; bu, keşif taramasına işaret edebilir.
• Yeni uç noktalar eklediğinizde, kimlik doğrulama mekanizmalarını değiştirdiğinizde veya yeni ön uç tüketicilerini dahil ettiğinizde CORS yapılandırmanızı yeniden denetleyin.
• Gerilemeleri tespit etmek için otomatik sürekli tarama kullanın — bağımlılıklar veya çerçeve varsayılanları değiştiğinde CORS politikaları sessizce gerileme yapabilir.