CORS

CORS Nedir?

Tarayıcı tabanlı uygulamalarda CORS, istemci tarafında çalışan JavaScript kodlarının hangi dış kaynaklara erişebileceğini belirleyen kritik bir güvenlik mekanizmasıdır. Varsayılan olarak tarayıcılar, bir web uygulamasının yalnızca kendi origin'i ile aynı olan kaynaklara erişmesine izin verir. CORS mekanizması, bu kısıtlamayı tamamen kaldırmak yerine sunucu tarafından açıkça tanımlanan kurallar çerçevesinde gevşetir.

CORS kapsamında sunucu; izin verilen origin'leri, HTTP metodlarını ve header'ları açıkça bildirerek tarayıcıya hangi isteklerin güvenli kabul edildiğini söyler. Tarayıcı da bu bilgilere göre isteğin gönderilmesine veya yanıtın JavaScript tarafından okunmasına izin verir. Bu sayede istemci tarafında ek bir güvenlik açığı oluşturulmadan, farklı domain'ler arasında kontrollü veri paylaşımı sağlanır.

Özetle CORS, tarayıcı güvenliğini korurken modern web uygulamalarının API, mikroservis ve üçüncü parti servislerle sorunsuz şekilde haberleşmesini mümkün kılan standart bir erişim kontrol mekanizmasıdır.

CORS Aksiyonu Nedir?

CORS (Cross-Origin Resource Sharing) aksiyonu, farklı origin'lerden (domain, protokol veya port) gelen HTTP isteklerine izin verme politikalarını yönetir. Bu aksiyon, tarayıcıların güvenlik politikalarını (Same-Origin Policy) kontrollü bir şekilde gevşetmenize olanak tanır.

Bu aksiyon hem istek (request) hem de yanıt (response) aşamasında çalışır. OPTIONS preflight isteklerini otomatik olarak işler ve gerekli CORS başlıklarını yanıtlara ekler.

CORS Aksiyonunun Önemi

Modern web uygulamaları genellikle farklı domain'lerden API çağrıları yapar. Tarayıcılar güvenlik nedeniyle bu istekleri varsayılan olarak engeller. CORS, bu kısıtlamayı kontrollü bir şekilde kaldırmanızı sağlar.

CORS aksiyonu;

• Frontend uygulamalarının farklı domain'deki API'lere erişmesini sağlar,
• Preflight (OPTIONS) isteklerini otomatik olarak işler,
• İzin verilen origin'leri, metodları ve başlıkları merkezi olarak yönetir,
• Güvenli bir şekilde cross-origin erişim politikaları tanımlar,
• Tek noktadan tüm vService için CORS yapılandırması sağlar.

Bu nedenle CORS aksiyonu, modern web API'leri ve SPA (Single Page Application) uygulamaları için kritik bir bileşendir.

CORS Nasıl Çalışır?

CORS mekanizması iki tür istek ile çalışır:

Basit İstekler (Simple Requests)

GET, HEAD veya POST metodları ile yapılan ve özel başlık içermeyen isteklerdir. Tarayıcı doğrudan isteği gönderir ve yanıttaki Access-Control-Allow-Origin başlığını kontrol eder.

Preflight İstekler

PUT, DELETE gibi metodlar veya özel başlıklar içeren isteklerden önce tarayıcı bir OPTIONS isteği gönderir. Bu istek, servisin asıl isteğe izin verip vermediğini kontrol eder.

Tarayıcı → TR7: OPTIONS preflight isteği

↓

TR7 → Tarayıcı: Access-Control-Allow-* başlıkları döner (Backend'e gitmeden)

↓

Tarayıcı → TR7: İzin verildiyse asıl istek gönderilir

Başlık	Açıklama
Access-Control-Allow-Origin	İzin verilen origin(ler)
Access-Control-Allow-Methods (yalnız preflight yanıtında)	İzin verilen HTTP metodları
Access-Control-Allow-Headers (yalnız preflight yanıtında)	İzin verilen özel başlıklar

TIP

TR7'nin CORS aksiyonu, preflight isteklerini Kurum Servisine göndermeden doğrudan yanıtlar. Bu, gereksiz Kurum Servisi yükünü ortadan kaldırır ve yanıt süresini kısaltır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir CORS Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak CORS seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Add butonuna tıklanarak aksiyon eklenir.

CORS Aksiyonu Ekleme Formu

CORS Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak CORS seçilir.

INFO

Hit Counter Varsayılan: Kapalı

Bu aksiyon koşul almadığından sayaç, Origin başlığı taşımayan istekler dahil her HTTP isteğinde artar; "CORS başlığı eklendi" sayısını değil, aksiyonun çalışma sayısını gösterir.

Hit Counter, aksiyonun her çalışmasını sayar (aksiyonun kendi koşuluyla birlikte değerlendirilir; Deny gibi sonlandırıcı aksiyonlarda bile sayım kaybolmaz). Aksiyon bazlı hız ve toplamlar, vService panosundaki Action Hits sekmesinde ve canlı istatistik ekranında görüntülenir; listelerde ayrıca bir kolon olarak görünmez. Sayaç kümülatiftir; elle sıfırlama arayüzü yoktur: sayılan aksiyon kümesi değiştiğinde veya vService yeniden yüklendiğinde sıfırdan başlar, geçmiş ise panoda hız (hit/s) olarak korunur.

INFO

Set Variable on Hit

Aksiyon her çalıştığında değeri atanacak bir değişken adı girilebilir (isteğe bağlı; varsayılan boş). Ad; harf, rakam ve alt çizgiden oluşabilir (en fazla 32 karakter). Aksiyon tetiklendiğinde değişken 1 değerine atanır ve aynı vService'teki diğer koşul ve aksiyonlarda %TR7VAR(ad) akıllı değişkeniyle okunarak zincirleme davranışlar kurulabilir.

INFO

Allowed Methods Zorunlu Varsayılan: *

Cross-origin isteklerde izin verilen HTTP metodları bu alanda girilir. Virgülle ayrılmış liste olarak girilir.

Alan boş bırakılamaz; varsayılan değeri *'dır ve alanın altında Örn: GET,PUT,POST biçiminde bir örnek gösterilir. Değerler virgülle ayrılır: aralarına boşluk konmamalıdır (a.com, * yazımında * joker olarak tanınmaz). Bu alanlar akıllı değişken (fx) desteklemez.

Yaygın değerler:

Değer	Açıklama
*	Tüm HTTP metodlarına izin ver
GET,POST	Sadece GET ve POST metodlarına izin ver
GET,POST,PUT,DELETE	RESTful API için tipik metodlar
GET,POST,PUT,DELETE,PATCH,OPTIONS	Tam RESTful API desteği

INFO

Allowed Origins Zorunlu Varsayılan: *

Cross-origin isteklere izin verilen kaynak domain'ler bu alanda girilir. Virgülle ayrılmış liste olarak girilir.

Alan boş bırakılamaz; varsayılan değeri *'dır ve alanın altında Örn: example.com,localhost,localhost:8080 biçiminde bir örnek gösterilir. Değerler virgülle ayrılır: aralarına boşluk konmamalıdır (a.com, * yazımında * joker olarak tanınmaz). Bu alanlar akıllı değişken (fx) desteklemez.

Desteklenen formatlar:

Format	Örnek	Açıklama
Wildcard	*	Tüm origin'lere izin ver
Tam URL	https://example.com	Sadece bu origin'e izin ver
Protokolsüz	example.com	HTTP ve HTTPS'e izin ver
Subdomain wildcard	.example.com	Tüm subdomain'lere izin ver
Port ile	https://example.com:8080	Belirli port'a izin ver
Port wildcard	https://example.com:*	Tüm portlara izin ver

Örnek konfigürasyonlar:

• *: Tüm origin'lere izin ver (geliştirme ortamı için)
• https://app.example.com: Sadece production frontend
• https://app.example.com,https://staging.example.com: Production ve staging
• .example.com: Tüm example.com subdomain'leri

WARNING

Production ortamında * kullanımından kaçınılır; yalnızca güvenilen origin'ler açıkça belirtilir.

INFO

Allowed Headers Zorunlu Varsayılan: *

Cross-origin isteklerde izin verilen özel HTTP başlıkları bu alanda girilir. Virgülle ayrılmış liste olarak girilir.

Alan boş bırakılamaz; varsayılan değeri *'dır ve alanın altında Örn: X-Custom-Header1,X-Custom-Header2 biçiminde bir örnek gösterilir. Değerler virgülle ayrılır: aralarına boşluk konmamalıdır (a.com, * yazımında * joker olarak tanınmaz). Bu alanlar akıllı değişken (fx) desteklemez.

Yaygın başlıklar:

Başlık	Kullanım Alanı
Content-Type	JSON, form data gönderimi
Authorization	Bearer token, API key
X-Requested-With	AJAX istekleri tanımlama
Accept	Kabul edilen içerik tipleri
Access-Control-Request-Method	Preflight için metod bildirimi

Örnek: Content-Type,Authorization,X-Requested-With,Accept

Davranış Ayrıntıları

• İstekte Origin başlığı yoksa aksiyon hiçbir şey yapmaz; sağlık kontrolleri ve sunucudan sunucuya çağrılar etkilenmez.
• Preflight (OPTIONS) istekleri Kurum Servisine gitmeden 204 No Content ile yanıtlanır. Origin izinli listede değilse yanıt yine 204 döner; yalnızca Access-Control-Allow-Origin başlığı eklenmez ve tarayıcı isteği engeller.
• Access-Control-Max-Age değeri 600 saniyedir ve değiştirilemez.
• Origin * değilse yanıta Vary: Accept-Encoding,Origin başlığı eklenir (önbellek/CDN davranışı için önemlidir).
• Access-Control-Allow-Credentials ve Access-Control-Expose-Headers başlıkları üretilmez. Bunlara ihtiyaç duyulursa Add HTTP Header aksiyonu kullanılır; kimlik bilgisi (credentials) gönderilen senaryolarda Allow-Origin değeri * olamaz.
• Origin listesinde .example.com yazımı alt alan adlarını kapsar; apex alan adı (example.com) kapsanmaz: ikisi de gerekiyorsa ayrı ayrı yazılır.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

WARNING

CORS aksiyonu koşul gerektirmez ve tanımlandığı vService üzerinde koşulsuz (Always) olarak uygulanır.

Koşulsuz çalışan aksiyonlar, trafik içeriğine bağlı değerlendirme yapmadan, ilgili vService üzerindeki tüm trafiği veya davranışı doğrudan etkiler.

Canlı ortamlarda, bu tür aksiyonların devreye alınması öncesinde hedef servis davranışlarının ve olası etkilerin dikkatle değerlendirilmesi önerilir. Aksi durumda, beklenmeyen servis davranışları veya operasyonel sorunlar oluşabilir.

Operasyonel ve Güvenli Kullanım Önerileri

• Production'da wildcard kullanılmaz. * değeri geliştirme ortamı için uygundur, ancak production'da güvenlik riski oluşturur; izin verilen origin'ler açıkça belirtilir.
• Credentials Desteği. TR7 Access-Control-Allow-Credentials başlığını üretmez; kimlik bilgisi taşıyan isteklerde bu başlık Add HTTP Header ile eklenmeli ve Allowed Origins alanında * yerine tam origin yazılmalıdır.
• Minimum izin prensibi uygulanır. Yalnızca gerçekten gerekli olan metotlara, origin'lere ve başlıklara izin verilir; gereksiz geniş izinler güvenlik açığı oluşturabilir.
• Subdomain wildcard dikkatli kullanılır. .example.com tüm subdomain'lere izin verir; subdomain'ler farklı güvenlik seviyelerindeyse her biri ayrı ayrı belirtilir.
• API ve Frontend Ayrımı. API vService'leri için CORS aktif edilmeli, ancak frontend sunucuları için genellikle gerekli değildir.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: React/Vue SPA ile API Entegrasyonu

Problem: React frontend uygulaması https://app.example.com adresinde, API ise https://api.example.com adresinde çalışıyor. Frontend'den yapılan AJAX istekleri browser tarafından "CORS policy" hatası ile engelleniyor.

Çözüm: API vService'ine CORS aksiyonu eklenerek frontend uygulamasına cross-origin erişim izni verilir.

Konfigürasyon:

• Allowed Methods: GET,POST,PUT,DELETE,PATCH
• Allowed Origins: https://app.example.com
• Allowed Headers: Content-Type,Authorization

Sonuç:

• ✅ app.example.com'dan gelen istekler → API'ye erişim sağlanır, CORS hatası alınmaz.
• ✅ Authorization header → JWT token ile authentication çalışır.
• ✅ RESTful metodlar → GET, POST, PUT, DELETE, PATCH desteklenir.
• ❌ Diğer domain'lerden gelen istekler → Browser tarafından engellenir.

Senaryo 2: Multi-Environment API Erişimi (Production, Staging, Dev)

Problem: Aynı API production, staging ve development ortamlarından kullanılıyor. Her ortam farklı domain'de çalışıyor ve developer'lar localhost'tan test yapıyor. Her seferinde CORS ayarı değiştirmek operasyonel yük oluşturuyor.

Çözüm: Tüm ortamları tek CORS aksiyonunda tanımlayarak esnek ve güvenli erişim sağlayın.

Konfigürasyon:

• Allowed Methods: GET,POST,PUT,DELETE
• Allowed Origins: https://app.example.com,https://staging.example.com,http://localhost:3000
• Allowed Headers: Content-Type,Authorization,X-Requested-With

Sonuç:

• ✅ Production (app.example.com) → API'ye erişim sağlar.
• ✅ Staging (staging.example.com) → API'ye erişim sağlar.
• ✅ Development (localhost:3000) → Developer'lar local'de test yapabilir.
• ❌ Diğer domain'ler → Browser tarafından engellenir.

Senaryo 3: Public Read-Only API (Hava Durumu, Döviz Kuru)

Problem: Hava durumu API'si herkesin kullanabileceği public bir servis ama sadece okuma (GET) izni verilmeli. Yazma metodlarına (POST, PUT, DELETE) hiçbir domain erişmemeli.

Çözüm: Tüm origin'lere yalnızca GET metodunda izin verilerek public API güvenli biçimde açılır.

Konfigürasyon:

• Allowed Methods: GET,HEAD,OPTIONS
• Allowed Origins: *
• Allowed Headers: Content-Type,Accept

Sonuç:

• ✅ Herhangi bir web sitesi → API'den veri okuyabilir (GET).
• ✅ Public erişim → Hava durumu/döviz kuru gibi public data paylaşılır.
• ❌ POST, PUT, DELETE metodları → tarayıcı tarafından engellenir.
• ❌ Veri yazma → Sadece okuma izni var, yazma yapılamaz.

Senaryo 4: Internal Microservices Cross-Origin İletişimi

Problem: Microservice mimarisinde farklı subdomain'lerde çalışan servisler (auth.internal.example.com, users.internal.example.com, orders.internal.example.com) birbirleriyle iletişim kuruyor. Browser tabanlı admin panel'den bu servislere AJAX istekleri yapılınca CORS hatası alınıyor.

Çözüm: Internal subdomain'lere wildcard CORS izni vererek mikroservislerin birbirleriyle serbestçe iletişim kurmasını sağlayın.

Konfigürasyon:

• Allowed Methods: *
• Allowed Origins: .internal.example.com
• Allowed Headers: *

Sonuç:

• ✅ auth.internal.example.com → users.internal.example.com'a erişebilir.
• ✅ orders.internal.example.com → Tüm internal servislere erişebilir.
• ✅ Tüm metodlar ve header'lar → Internal servisler arasında kısıtlama olmaz.
• ❌ External domain'ler → .internal.example.com dışındaki domain'ler engellenir.