ASP.NET Core CORS yapılandırması

Mehmet · Dün 20:56 da

ASP.NET Core CORS yapılandırması

ASP.NET Core’da CORS’u, izin verilecek kaynakları belirleyen bir politika tanımlayıp bu politikayı istek hattına ekleyerek yapılandırırsınız. Aşağıdaki en küçük örnek, yalnızca https://example.com kaynağından gelen tarayıcı isteklerinin /api/ping uç noktasının yanıtını JavaScript ile okumasına izin verir. API’yi doğrudan çağırmayı engellemez.

Çalışan en küçük örnek

WebApplication kullanan modern, HTTPS erişimi çalışır bir ASP.NET Core minimal API projesindeki Program.cs dosyasını şu yapıya getirin:

Kod:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy("FrontendPolicy", policy =>
    {
        policy.WithOrigins("https://example.com")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

app.UseHttpsRedirection();
app.UseRouting();
app.UseCors("FrontendPolicy");

app.MapGet("/api/ping", () => Results.Ok(new { message = "pong" }));

app.Run();

Uygulamayı çalıştırın; önce API’nin nihai HTTPS adresinin ve geliştirme sertifikasının kullanılabildiğini doğrulayın. İstekleri HTTP adresine gönderip HTTPS yönlendirmesine bırakmak preflight hatası doğurabilir. Ardından izinli https://example.com sayfasından API’ye istek gönderin. İzin verilen kaynakla yapılan başarılı yanıtta sunucu, CORS için gerekli yanıt başlıklarını ekler ve JavaScript isteği yanıtı okuyabilir. Tarayıcı CORS hatası verirse önce isteği yapan sayfanın kaynağını ve politikadaki WithOrigins değerini karşılaştırın. curl gibi araçlar CORS’u uygulamadığından, yalnızca komut satırında başarılı sonuç almak tarayıcı erişiminin de başarılı olduğunu göstermez.

Yapılandırma nasıl çalışır?

Bir kaynak; şema, alan adı ve portun birleşimidir. Örneğin http://example.com, https://example.com ile aynı kaynak değildir. Port da karşılaştırmaya dahildir. WithOrigins içine API’ye çağrı yapan gerçek ön yüz kaynaklarını yazın; yol bölümünü ve sondaki eğik çizgiyi eklemeyin.

AllowAnyMethod tüm HTTP yöntemlerine, AllowAnyHeader ise istemcinin özel istek başlıklarına izin verir. Üretimde yalnızca ihtiyaç duyulan yöntem ve başlıkları belirtmek, politikanın kapsamını daha anlaşılır tutar.

CORS’un kimlik doğrulama olmadığını da unutmayın. Bu ayar, tarayıcının farklı bir kaynaktan gelen yanıtı JavaScript koduna açıp açmayacağını belirler; API’nin yetkilendirme kontrolünü ortadan kaldırmaz.

İhtiyaca göre karar tablosu

Aşağıdaki seçim, politikanın gereğinden geniş tanımlanmasını önlemeye yardımcı olur.

İhtiyaç	Tercih	Dikkat edilmesi gereken
Tek bir ön yüz	`WithOrigins(...)`	Kaynak tam ve doğru yazılmalıdır
Birden fazla ön yüz	Birden fazla izinli kaynak	Yalnız bilinen kaynakları ekleyin
Kimlik bilgisi veya çerez	`AllowCredentials()`	Herhangi bir kaynakla birlikte kullanılmamalıdır
Genel, kimliksiz API	`AllowAnyOrigin()`	Tarayıcı erişimini gereksiz yere genişletebilir

Çerez veya tarayıcı kimlik bilgisi gönderilecekse politika şu biçimde genişletilebilir:

Kod:

policy.WithOrigins("https://example.com")
      .AllowAnyHeader()
      .AllowAnyMethod()
      .AllowCredentials();

Çerez gönderilecekse istemci isteğinde uygun credentials seçeneği de gerekir; çerezin SameSite/Secure ve tarayıcı üçüncü taraf çerez koşulları ayrıca geçerlidir. Bu durumda AllowAnyOrigin ile AllowCredentials birlikte kullanılmamalıdır. Tarayıcılar bu kombinasyonu geçerli bir CORS politikası olarak kabul etmez.

Uygulama sırası ve preflight istekleri

Bazı çapraz kaynak isteklerinden önce tarayıcı, asıl isteğin yapılıp yapılamayacağını OPTIONS yöntemiyle sorar. Buna preflight denir. CORS middleware’i rota eşlemesinden sonra, yetkilendirme ve uç noktanın çalıştırılmasından önce çalışmalıdır. Bu nedenle örnekte UseRouting ardından UseCors gelir. MapGet satırlarının dosyadaki konumuyla middleware’in çalışma sırasını birbirine karıştırmayın.

Kimlik doğrulama veya yetkilendirme eklediğiniz bir uygulamada CORS’u ilgili istek hattında yine yetkilendirme kararlarından önce çalıştırın. Aksi durumda hata yanıtında gerekli CORS başlıkları bulunmayabilir ve gerçek sunucu hatası tarayıcıda yalnızca genel bir CORS hatası gibi görünebilir.

Sık yapılan hatalar

İzin verilen kaynağa yol eklemek: https://example.com/app bir kaynak tanımı değildir; yalnızca şema, alan adı ve port kullanılır.
HTTP ve HTTPS’yi aynı sanmak: Geliştirme ortamındaki HTTP kaynağı ile HTTPS kaynağı ayrı ayrı değerlendirilir.
Politikayı tanımlayıp middleware’i eklememek: AddCors tek başına isteklere başlık eklemez; UseCors de çağrılmalıdır.
Sadece sunucu aracında test yapmak: CORS kısıtlaması tarayıcı davranışıdır; testi gerçek farklı kaynaklı bir web sayfasından yapın.
CORS’u güvenlik duvarı veya yetkilendirme yerine kullanmak: İzin verilen kaynak listesi, API’ye doğrudan yapılan istekleri kimlik doğrulamasız hâle getirmez.

Sık sorulan sorular

Geliştirme ve üretim için ayrı CORS politikası kullanmalı mıyım?

Evet. Geliştirme kaynağını üretim politikasına taşımak yerine ortam yapılandırmasıyla izinli kaynakları ayrı yönetin. Böylece test adresleri üretimde gereksiz erişim alanı oluşturmaz.

İzin verilmeyen kaynakla testte API hiç çağrılmaz mı?

Hayır. Basit çapraz kaynak isteği sunucuya ulaşabilir, fakat JavaScript yanıtı okuyamaz. Preflight gerektiren istekte ise başarısız ön kontrolden sonra asıl istek gönderilmez. İzinli ve izinsiz kaynaklardan test edip yanıt başlıklarını bu ayrımla değerlendirin.

CORS hatası API’nin çalışmadığı anlamına mı gelir?

Hayır. API yanıt üretiyor olabilir; sorun, tarayıcının bu yanıtı çağıran JavaScript koduna vermeyi engellemesi olabilir. Önce yanıtın durum kodunu, ardından CORS başlıklarını ve isteğin kaynak bilgisini birlikte inceleyin.

ASP.NET Core CORS yapılandırması

Mehmet