Kaynaklar Arası Varlık Paylaşımı nedir?
Kaynaklar arası varlık paylaşımı (CORS), uygulamaları entegre etmeye yarayan bir mekanizmadır. CORS, bir etki alanına yüklenen istemci web uygulamalarının farklı bir etki alanındaki varlıklarla etkileşime girmesi için bir yol tanımlar. Karmaşık uygulamalar genellikle istemci tarafı kodlarında üçüncü taraf API'lere ve varlıklara başvurduğundan, bu yol kullanışlıdır. Örneğin uygulamanız tarayıcınızı bir video platformu API'sinden video çekmek, herkese açık bir yazı tipi kitaplığından yazı tiplerini kullanmak veya ulusal hava durumu veritabanından hava durumu verilerini görüntülemek için kullanabilir. CORS sayesinde istemci tarayıcısı, herhangi bir veri aktarımı öncesinde talebin onaylanıp onaylanmadığının üçüncü taraf sunucularla kontrolünü sağlar.
Kaynaklar arası varlık paylaşımı neden önemlidir?
Geçmişte, internet teknolojileri hâlâ yeniyken, siteler arası istek sahteciliği (CSRF) sorunları yaşanıyordu. Bu sorunlar, mağdurun tarayıcısından başka bir uygulamaya sahte müşteri istekleri gönderiyordu.
Örneğin, mağdur kişi bankasının uygulamasında oturum açıyor. ve ardından, yeni bir tarayıcı sekmesinde harici bir web sitesini yüklemesi için kandırılıyordu. Harici web sitesi daha sonra mağdurun çerez kimlik bilgilerini kullanıyor ve mağdur gibi davranarak verileri banka uygulamasına aktarıyordu. Böylece yetkisiz kullanıcılar, banka uygulamasına istenmeyen erişime sahip oluyordu.
Bu tür CSRF sorunlarını önlemek için artık tüm tarayıcılar aynı kaynak politikasını uyguluyor.
Aynı kaynak politikası
Günümüzde tarayıcılar, istemcilerin yalnızca istemcinin URL'si ile aynı kaynağa sahip bir varlığa istek gönderebilmesini zorunlu kılıyor. İstemci URL'sinin protokolü, bağlantı noktası ve ana sunucu adı, istekte bulunduğu sunucuyla eşleşmelidir.
Örneğin, müşteri URL'si http://store.aws.com/dir/page.html olan aşağıdaki URL'ler için kaynak karşılaştırmasını göz önünde bulundurun.
| URL |
Sonuç |
Sebep |
| http://store.aws.com/dir2/new.html |
Aynı kaynak |
Yalnızca yol farklıdır |
| http://store.aws.com/dir/inner/other.html |
Aynı kaynak |
Yalnızca yol farklıdır |
| https://store.aws.com/page.html |
Farklı kaynak |
Farklı protokol |
| http://store.aws.com:81/dir/page.html |
Farklı kaynak |
Farklı bağlantı noktası (http:// varsayılan olarak bağlantı noktası 80'dir) |
| http://news.aws.com/dir/page.html |
Farklı kaynak |
Farklı ana sunucu |
Yani, aynı kaynak politikası son derece güvenlidir ancak gerçek kullanım örnekleri için esnek değildir.
Kaynaklar arası varlık paylaşımı (CORS), aynı kaynak politikasının bir uzantısıdır. Harici üçüncü taraflarla yetkili varlık paylaşımı için buna ihtiyacınız vardır. Örneğin, herkese açık veya yetkili harici API'lerden veri almak istediğinizde CORS'ye ihtiyaç duyarsınız. Kendi sunucu varlıklarınız için yetkili üçüncü taraf erişimine izin vermek istiyorsanız da CORS'ye ihtiyaç duyarsınız.
Kaynaklar arası varlık paylaşımı nasıl çalışır?
Standart internet iletişiminde, tarayıcınız uygulama sunucusuna bir HTTP isteği gönderir, verileri HTTP yanıtı olarak alır ve görüntüler. Tarayıcı terminolojisinde, geçerli tarayıcı URL'sine geçerli kaynak ve üçüncü taraf URL'sine kaynaklar arası adı verilir.
Kaynaklar arası bir istekte bulunduğunuzda, bu bir istek-yanıt işlemidir:
- Tarayıcı, istek için geçerli kaynak protokolü, ana sunucu ve bağlantı noktası hakkındaki bilgileri içeren bir kaynak başlığı ekler.
- Sunucu geçerli kaynak başlığını kontrol eder ve istenen verilerle ve bir Access-Control-Allow-Origin başlığıyla yanıt verir.
- Tarayıcı, erişim denetimi istek başlıklarını görür ve döndürülen verileri istemci uygulamasıyla paylaşır.
Alternatif olarak, sunucu kaynaklar arası erişime izin vermek istemiyorsa bir hata mesajıyla yanıt verir.
Kaynaklar arası varlık paylaşımı örneği
Örneğin, https://news.example.com adlı bir siteyi düşünün. Bu site, partner-api.com adresindeki bir API'den varlıklara erişmek istiyor.
https://partner-api.com adresindeki geliştiriciler önce, izin verilen kaynaklar listesine new.example.com'u ekleyerek sunucularında kaynaklar arası varlık paylaşımı (CORS) başlıklarını yapılandırır. Bunu, sunucu yapılandırma dosyalarına aşağıdaki satırı ekleyerek yaparlar.
Access-Control-Allow-Origin: https://news.example.com
CORS erişimi yapılandırıldıktan sonra news.example.com, partner-api.com'dan varlık isteyebilir. partner-api.com, her istek için Access-Control-Allow-Credentials : "true" ile yanıt verecektir. Tarayıcı daha sonra iletişimin yetkili olduğunu öğrenir ve kaynaklar arası varlık erişimine izin verir.
Birden fazla kaynak için erişim izni vermek istiyorsanız virgülle ayrılmış bir liste veya herkese erişim sağlayan * gibi joker karakterler kullanın.
CORS preflight isteği nedir?
HTTP'de istek yöntemleri, istemcinin, sunucunun gerçekleştirmesini istediği veri işlemleridir. GET, POST, PUT ve DELETE, başlıca HTTP yöntemleri arasında yer alır.
Düzenli bir kaynaklar arası varlık paylaşımı (CORS) etkileşiminde, tarayıcı istek ve erişim denetimi başlıklarını aynı anda gönderir. Bunlar genellikle GET veri istekleridir ve düşük riskli olarak kabul edilir.
Ancak bazı HTTP istekleri karmaşık olarak kabul edilir ve gerçek istek gönderilmeden önce sunucu onayı gerektirir. Ön onay sürecine preflight isteği denir.
Karmaşık kaynaklar arası istekler
Kaynaklar arası istekler, aşağıdakilerden herhangi birini kullandığında karmaşık hale gelir:
- GET, POST veya HEAD dışındaki yöntemler
- Accept-Language, Accept veya Content-Language dışındaki başlıklar
- multipart/form-data, application/x-www-form-urlencoded veya text/plain dışındaki Content-Type başlıkları
Bu nedenle, örneğin, mevcut verileri silme veya değiştirme istekleri karmaşık olarak kabul edilir.
Preflight istekleri nasıl çalışır?
Tarayıcılar, ihtiyaç duyulduğunda preflight istekleri oluşturur. Bu, aşağıdaki gibi bir OPTIONS isteğidir.
| OPTIONS /data HTTP/1.1 Kaynak: https://ornek.com Access-Control-Request-Method: DELETE |
Tarayıcı, preflight isteğini gerçek istek mesajından önce gönderir. Sunucu, preflight isteğine, sunucunun istemci URL'sinden kabul etmek istediği kaynaklar arası varlık istekleri hakkındaki bilgilerle yanıt vermelidir. Sunucu yanıt başlıkları aşağıdakileri içermelidir:
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Origin
Örnek bir sunucu yanıtı aşağıda verilmiştir.
| HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS |
Preflight yanıtı bazen ek bir Access-Control-Max-Age başlığı içerir. Bu ölçüm, tarayıcının preflight sonuçlarını tarayıcıda önbelleğe alma süresini (saniye cinsinden) belirtir. Önbelleğe alma, tarayıcının preflight istekleri arasında birkaç karmaşık istek göndermesine olanak tanır. Max-age tarafından belirtilen süre geçene kadar başka bir preflight isteği göndermesi gerekmez.
CORS ile JSONP arasındaki fark nedir?
JSON with Padding (JSONP), farklı etki alanlarında çalışan web uygulamaları arasında iletişime izin veren eski bir tekniktir.
JSONP ile, istemci sayfasında HTML betiği etiketlerini kullanırsınız. Betik etiketi harici JavaScript dosyalarını yükler veya JavaScript kodunu doğrudan bir HTML sayfasına gömer. Betikler aynı kaynak politikasına tabi olmadığından, JavaScript kodu aracılığıyla kaynaklar arası verileri alabilirsiniz.
Ancak, veriler JSON biçiminde olmalıdır. Ayrıca JSONP, güvenli veri sağlamak için harici etki alanının güvenilirliğine dayandığı için kaynaklar arası varlık paylaşımından (CORS) daha az güvenlidir.
Modern tarayıcılar bazı güvenlik özellikleri eklediğinden JSONP içeren eski kod artık bunlar üzerinde çalışmayacaktır. CORS, kaynaklar arası varlık erişim denetimi için mevcut küresel web standardıdır.
Bazı CORS en iyi uygulamaları nelerdir?
Sunucunuzda kaynaklar arası varlık paylaşımını (CORS) yapılandırırken aşağıdakilere dikkat etmelisiniz.
Uygun erişim listelerini tanımlayın
Virgülle ayrılmış listeler kullanarak etki alanlarına tek tek erişim vermek her zaman en iyisidir. API'yi herkese açık hale getirmek istemediğiniz sürece joker karakter kullanmaktan kaçının. Aksi takdirde, joker karakterler ve normal ifadeler kullanmak güvenlik açıkları oluşturabilir.
Örneğin, permitted-website.com son eki ile tüm sitelere erişim izni veren bir normal ifade yazdığınızı varsayalım. Tek ifadeyle, api.permitted-website.com ve news.permitted-website.com adreslerine erişim izni veriyorsunuz. Ancak, maliciouspermitted-website.com gibi etki alanlarını kullanabilecek yetkisiz sitelere de istemeden erişim izni veriyorsunuz.
Listenizde null kaynak kullanmaktan kaçının
Bazı tarayıcılar, dosya istekleri veya yerel ana sunucudan gelen istekler gibi belirli senaryolar için istek başlığında null değerini gönderir.
Ancak, null değerini erişim listenize eklememelisiniz. Bu ayrıca, null başlıklar içeren yetkisiz istekler erişim sağlayabileceğinden güvenlik riskleri de getirir.
AWS, CORS gereksinimlerinizi nasıl destekleyebilir?
Hizmetlerimizin çoğu yerleşik kaynaklar arası varlık paylaşımı (CORS) desteğine sahiptir. Böylece API'lerinize ve Amazon Web Services (AWS) üzerinde barındırılan kaynaklara kaynaklar arası erişimi denetleyebilirsiniz.
CORS desteğine sahip bazı AWS hizmetleri şunlardır:
- Amazon Basit Depolama Hizmeti (Amazon S3), tüm veri depolama kullanım örneklerine yönelik olarak uygun maliyetli depolama sınıflarına sahip bir nesne depolama hizmetidir. Amazon S3; S3 verilerinize, her kaynak için destekleyeceğiniz operasyonlara (HTTP yöntemleri) ve operasyona özgü diğer bilgilere erişmesine izin vereceğiniz kaynakları tanımlayan kurallarla bir CORS yapılandırma belgesi oluşturmanıza olanak tanır. Yapılandırmaya 100 adede kadar kural ekleyebilirsiniz.
- Amazon API Ağ Geçidi, istenen ölçekte API'ler oluşturulup yayımlanmasını, bunların izlenmesini, bakımın yapılmasını ve güvenliğinin sağlanmasını mümkün kılan, tam olarak yönetilen bir hizmettir. REST API'leriniz için CORS'yi, doğrudan Amazon API Ağ Geçidi konsolunda tek tıklamayla etkinleştirebilirsiniz.
Hemen bir hesap oluşturarak AWS'de API'leri kullanmaya başlayın.
