React Server Components Güvenlik Açıkları Bize Ne Anlatıyor?

React uygulamalarında güvenlik denildiğinde uzun süre benzer konular konuşuldu.

XSS açıkları, kullanıcı girdilerinin doğrulanması, token saklama yöntemleri, bağımlılıkların güncel tutulması…

Bunlar hâlâ önemli.

Ancak React Server Components mimarisiyle birlikte başka bir konu daha görünür hâle geldi: Bir frontend teknolojisinin sunucu tarafındaki yürütme modeli, uygulamanın güvenlik yüzeyini doğrudan etkileyebiliyor.

3 Aralık 2025'te React ekibi, Server Components ile ilişkili kritik bir güvenlik açığı duyurdu. CVE-2025–55182 olarak tanımlanan açık, belirli koşullarda kimlik doğrulama olmadan uzaktan kod çalıştırmaya olanak tanıyordu.

Sonraki aylarda hizmet engelleme ve kaynak kodunun açığa çıkması gibi farklı güvenlik sorunları için de duyurular yayımlandı.

14 Ekim 2026 tarihli React güvenlik kayıtlarında yeni kritik ve yüksek önem dereceli bildirimlerin bulunması, bu konunun yalnızca geçmişte kalmış tek bir olay olarak ele alınamayacağını gösteriyor.

Frontend artık her zaman yalnızca frontend değil

React geliştiricileri geleneksel olarak tarayıcıda çalışan component'ler üzerinden düşünmeye alışkın.

Bir kullanıcı etkileşimi gerçekleşir, state değişir, arayüz yeniden değerlendirilir.

Sunucuyla iletişim çoğunlukla API istekleri üzerinden yürür.

Server Components ve Server Functions ise bu ayrımın bazı yönlerini değiştiriyor.

Component'lerin bir bölümü sunucuda çalışabiliyor. Sunucu tarafındaki fonksiyonlar belirli mekanizmalar üzerinden istemci tarafından çağrılabiliyor. Framework'ler bu iletişimin çeşitli ayrıntılarını geliştiriciden soyutlayabiliyor.

Bu yaklaşımın faydaları var.

Sunucu tarafındaki verilere erişim kolaylaşabiliyor, istemciye gönderilen JavaScript miktarı azaltılabiliyor ve bazı işlemler daha doğal biçimde sunucu ortamında gerçekleştirilebiliyor.

Ancak bu mimari yeni güvenlik sorumlulukları da beraberinde getiriyor.

Tarayıcıda çalışan bir component ile sunucuda çalışan bir fonksiyon aynı güven sınırına sahip değil.

Güvenlik açığının dikkat çekici tarafı

Aralık 2025'te duyurulan kritik açık, React Server Function uç noktalarına gönderilen verilerin işlenmesiyle ilişkiliydi.

React'in resmî açıklamasına göre güvenlik sorunu, gelen HTTP yüklerinin çözümlenmesi sırasında ortaya çıkabiliyordu.

Dikkat çekici noktalardan biri, uygulamanın doğrudan bir Server Function tanımlamamış olmasının her durumda güvenli olduğu anlamına gelmemesiydi.

Etkilenen React Server Components altyapısını kullanan uygulamaların da risk altında olabileceği belirtilmişti.

Bu ayrıntı önemli.

Çünkü geliştiriciler bazen güvenlik yüzeyini yalnızca kendi yazdıkları API endpoint'leri üzerinden değerlendiriyor.

Oysa framework'ün kendi protokolleri, veri işleme mekanizmaları ve bağımlılıkları da uygulamanın erişilebilir yüzeyinin parçası olabilir.

Sorun yalnızca uygulama kodunda bulunmaz.

Kullanılan altyapının davranışı da önemlidir.

Güncelleme yapmak her zaman süreci bitirmiyor

İlk güvenlik açığının ardından düzeltmeler yayımlandı.

Ancak React ekibinin daha sonra yaptığı açıklamalarda, ilişkili başka güvenlik sorunlarının bulunduğu ve bazı önceki düzeltme sürümlerinin yeterli olmadığı belirtildi.

Bu nedenle başlangıçta yapılan bir güncellemenin bütün riskleri ortadan kaldırdığını varsaymak doğru değildi.

Bu durum yazılım bağımlılıklarında sık karşılaşılan bir sorunu hatırlatıyor.

Bir güvenlik bildirimi yayımlandığında ekipler genellikle hızlı hareket ediyor.

Paket sürümü yükseltiliyor, uygulama derleniyor, testler çalıştırılıyor ve dağıtım yapılıyor.

Ardından görev kapatılıyor.

Fakat aynı sorun ailesi için yeni bildirimler yayımlanabilir. İlk düzeltme başka bir davranışı etkileyebilir veya aynı protokol üzerinde farklı bir güvenlik problemi keşfedilebilir.

Bu yüzden tek seferlik güncelleme ile sürdürülebilir güvenlik takibi aynı şey değil.

Kullandığınız sürümü gerçekten biliyor musunuz?

Bir projede react paketinin sürümünü kontrol etmek her zaman yeterli olmayabilir.

Uygulamanın kullandığı framework, sunucu bileşenleriyle ilişkili paketleri ve dolaylı bağımlılıkları da değerlendirmek gerekir.

Örneğin npm kullanan bir projede şu komut başlangıç noktası olabilir:

npm ls react react-dom \
  react-server-dom-webpack \
  react-server-dom-turbopack \
  react-server-dom-parcel

npm ls react react-dom \
  react-server-dom-webpack \
  react-server-dom-turbopack \
  react-server-dom-parcel

Bu komut, ilgili paketlerin kurulu bağımlılık ağacındaki durumunu görmeye yardımcı olur.

Ancak bir paketin listede görünmesi tek başına uygulamanın ilgili güvenlik açığından etkilendiğini kanıtlamaz.

Benzer şekilde, listede görünmemesi bütün güvenlik sorunlarının dışlandığı anlamına gelmez.

Framework'ün güvenlik duyuruları, kilit dosyası, dağıtılan sürüm ve resmî etkilenen sürüm aralıkları birlikte değerlendirilmelidir.

Özellikle monorepo yapılarında farklı uygulamaların farklı bağımlılık sürümleri kullanması mümkündür.

Geliştirme ortamında güncellenmiş görünen bir paket, üretimde çalışan bütün dağıtımlara henüz ulaşmamış olabilir.

Server Functions normal fonksiyonlar gibi düşünülmemeli

Bir Server Function sunucuda çalışıyor diye otomatik olarak güvenli kabul edilemez.

İstemciden çağrılabilen bir işlem, uygun yetkilendirme ve doğrulama kontrolleri gerektirir.

Örneğin kullanıcıya ait bir kaydı güncelleyen sunucu işlemi düşünelim.

async function updateProfile(
  userId: string,
  displayName: string
) {
  // Database update
}

async function updateProfile(
  userId: string,
  displayName: string
) {
  // Database update
}

Burada yalnızca userId parametresini almak yeterli değildir.

İsteği yapan kullanıcının kimliği güvenilir bir oturum mekanizmasıyla belirlenmeli, ilgili kaydı değiştirme yetkisi kontrol edilmeli ve girdi doğrulanmalıdır.

Fonksiyonun sunucuda çalışması, bu kontrollerin yerini almaz.

Bu örnek, React'in belirli bir güvenlik açığının doğrudan gösterimi değildir. Server Functions tasarımında dikkate alınması gereken daha genel bir güvenlik sınırını anlatır.

Modern frontend ekiplerinin değişen sorumluluğu

Bugün frontend geliştiricisi yalnızca tarayıcıdaki arayüz davranışını yönetmiyor olabilir.

Sunucu tarafında veri erişimi, cache davranışı, kimlik doğrulama sınırları ve framework protokolleri de geliştirme sürecinin parçası hâline gelebiliyor.

Bu değişim mutlaka olumsuz değil.

Bazı mimariler uygulama geliştirmeyi daha tutarlı ve verimli hâle getirebilir.

Ancak kolaylaşan geliştirme deneyimi, alttaki güvenlik sorumluluklarının ortadan kalktığı anlamına gelmiyor.

React Server Components güvenlik duyuruları da bu yüzden yalnızca belirli paketlerin güncellenmesiyle ilgili haberler değil.

Frontend mimarisinin giderek daha fazla sunucu sorumluluğu üstlendiği bir dönemin somut örnekleri.

Arayüz kodu ile sunucu kodu aynı projede, benzer dosyaların içinde ve ortak araçlarla geliştirilebilir.

Ama sunucuya gelen güvenilmeyen veriyle kurulan ilişki değişmez.

O sınırın nereden geçtiğini bilmek hâlâ gerekiyor.