CORS pratik kullanım senaryoları

Bu flood’da önceki flood’da ne işe yaradığını öğrendiğimiz CORS (Cross Origin Request Sharing)'un pratik kullanım senaryolarını anlatacağım.

Önceki flood’da CORS'un ne işe yaradığına değinmiş ve tarayıcının OPTIONS isteği ile istemcinin hedef orijinde yapabileceği istek (PUT, vb) ve ayarlayabileceği HTTP başlık tiplerini sorguladığını söylemiştik.

Tarayıcının her istekten önce OPTIONS göndermesi tahmin edilebileceği gibi sayfa performansını olumsuz yönde etkileyecektir. Bu noktada sunucu tarafı HTTP cevap başlığına access-control-max-age: 84600 ekleyerek tarayıcının CORS ayarlarını cache'lemesini sağlayabilir.

Chrome'un da dahil olduğu birçok tarayıcı, CORS ayarlarının cache'lenebileceği maksimum süreyi güvenlik sebebiyle 10 dakika civarında belirlemişlerdir. Dolayısıyla sunucudan gelecek daha uzun değerler tarayıcı tarafından 600 saniye ile sınırlanacaktır.

Tarayıcıların CORS preflight cache süresini sınırlamalarının sebebi bir orijin için güvensiz ağda cache'ledikleri CORS ayarlarının uzun süre taşınmasına engel olmaktır.

Bu arada tarayıcılar CORS preflight cache'i istek bazında yaparlar, yani PUT /api/books/4 isteği için CORS ayarları cache'lense bile PUT /api/books/5 ya da DELETE /api/books/4 istekleri için geçerli olmayacaktır. Dolayısıyla her durumda etkili değildir.

CORS politikaları sadece tarayıcılar tarafından uyguladığı için CORS'u aşmak üzere bir proxy konumlandırılıp istekler sunucuya bu proxy üzerinden yapılabilir. Aşağıdaki çizimde A'dan B'ye yapılan istekler proxy üzerinden geçerek yapılmış ve CORS atlatılmıştır.

Görüleceği üzere bir proxy kullanılarak CORS politikaları kolaylıkla bypass edilerek etkisiz bırakılmıştır. Bu noktada akla "Bu kadar kolay alt edilebiliyorsa CORS politikaları neden hala uygulanıyor?" sorusu gelmelidir.

proxy sunucu kullanılarak B'ye yapılması gereken istekler aslında B yerine A orijininde yayın yapan proxy'ye yapıldığı için tarayıcı B orijinine istek yapılırken göndereceği cookie ve diğer özel bilgileri A orijine göndermeyecek ve güvenlik riski oluşmayacaktır.

Web ve uygulama sunucularının aynı orijinde olduğu kullanım senaryolarında CORS politikaları devreye girmez çünkü tarayıcı bütün istekleri aynı orijine yapar. Web ve uygulama sunucularının farklı orijinlerde olduğu senaryolarda ise CORS'u aşmak gerekecektir. Örneğin, www․xyz․com üzerinden yüklenen web sitesinin api․xyz․com'dan API çağrıları yapması gerekebilir. Burada en doğru ve genel yöntem CORS politikaları ile www․xyz․com'dan api․xyz․com'a yapılacak isteklere izin vermektir.

Alternatif olarak CORS'un devreye girmemesi için, web ve uygulama sunucusu aynı domain üzerinde konumlandırılabilir. Bu sunucuların önünde konumlandırılan bir reverse proxy veya load balancer da bu sunuculara gönderilen istekleri URL'e bakarak ayırt eder ve yönlendirir.

Üretim ortamında CORS politikaları doğru olarak ayarlanıp kullanılsa bile geliştirme ortamında da CORS politikalarının ya doğru ayarlanması ya da bypass edilmesi gerekmektedir. Bu ihtiyacı görmek üzere çeşitli araçlar bulunabilir.

Son olarak React, Angular ve Vue.js gibi popüler ön yüz geliştirme araçlarında ağırlıklı olarak kullanılan webpack'te bulunan dahili web sunucu aşağıdaki gibi konfigüre edildiğinde proxy görevi de görerek bir path'e gelen istekleri istenen porta yönlendirebilir.