← Radar

Konu: Web3 dk okuma

Next.js'te tek seferde 13 açık: Middleware neden kapı bekçisi değildir?

Bu neden önemli?

Next.js en yaygın React framework'ü. Kendi sunucunda çalıştırıyorsan bu açıkların bir kısmı seni doğrudan ilgilendiriyor. Asıl önemli olan da şu: Güncellemek bu sefer yetiyor ama giriş kontrolünü sadece middleware'e emanet edersen bir sonraki açıkta yine açıkta kalırsın.

Ne oldu?

Vercel, 7 Mayıs 2026’da Next.js için toplu bir güvenlik güncellemesi yayımladı: 13 açık, çoğu “yüksek” önem derecesinde. Bir kısmı React’in sunucu bileşenlerini (React Server Components, RSC) çalıştıran react-server-dom-* paketlerinde, yani bu paketleri kullanan başka framework’leri de ilgilendiriyor. Çözüm tek: Next.js 15.5.18 ya da 16.2.6’ya geçmek. 13.x ve 14.x için ayrı düzeltme yok, bu sürümlerdeysen büyük sürüm atlaman gerekiyor. Vercel, bu açıkların güvenlik duvarı (WAF) kurallarıyla güvenilir şekilde engellenemeyeceğini de söylüyor.

Better Stack videosunda her kategoriden bir açığı canlı olarak yeniden üretiyor. Biz de kategorilere bakıp her birinin dersini çıkaralım.

1. Middleware’i atlatmak

Next.js’te middleware (Next.js 16’da adı proxy oldu), her istekten önce çalışan bir kod parçası. Çoğu kişi burada “giriş yapmamışsa login sayfasına yönlendir” kontrolü yapıyor. Bu güncellemedeki dört yüksek dereceli açık, tam bu kontrolün atlatılmasıyla ilgili. Aynı sayfaya farklı bir URL biçimiyle ulaşmak yetiyordu: Sayfa önceden yüklenirken kullanılan .rsc ve segment-prefetch adresleri, dinamik route parametresini değiştiren özel sorgu parametreleri ya da çok dilli (i18n) sitelerde dil öneki olmayan veri adresi. Middleware’in eşleştirme kuralı bu varyantları yakalamıyordu, sayfa korumasız açılıyordu.

Videodaki yorum yerinde: Bu açıklar kulağa olduğundan daha kötü geliyor, çünkü Next.js zaten middleware’i tek koruma olarak kullanmanı önermiyor. Dokümantasyon, proxy’deki kontrolü “iyimser” bir ön filtre olarak görüyor. Asıl kontrol veriye en yakın yerde, bir Data Access Layer içinde yapılmalı: Sunucu bileşeninde, route handler’da ve her server action’da oturumu yeniden doğrula. Bunu yapan bir uygulamada middleware atlatılsa bile korunan veri açığa çıkmaz; Next.js’in kendi önerdiği geçici çözüm de tam olarak bu.

2. Sunucuyu kilitlemek (DoS)

En öğretici açıklardan biri React’in Flight protokolünde, yani sunucu ile tarayıcı arasında bileşen ve veri taşıyan formatta. Videoya göre, bir server action’a giden isteğe on binlerce sahte alan ve binlerce referans eklendiğinde, sunucu her referans için bütün alanları baştan tarıyordu. İş miktarı “referans sayısı çarpı alan sayısı” kadar büyüyor, tek bir istek sunucuyu saniyelerce meşgul ediyordu. Düzeltme, listeyi geri dönmeyen tek bir imleçle taramak: İş, çarpımdan toplama iniyor. Kendi protokolünü ve ayrıştırıcını (parser) yazmanın neden zor olduğunu gösteren güzel bir örnek.

3. Sunucuya iç ağa istek attırmak (SSRF)

En yüksek puanlı açık (8.6) yalnızca kendi sunucusunda Next.js çalıştıranları etkiliyor; Vercel’de barınan siteler etkilenmiyor. Özel hazırlanmış bir WebSocket “upgrade” isteğiyle Next.js sunucusu, saldırganın seçtiği bir adrese istek atıyordu. Dışarıya kapalı bir veritabanı paneli ya da bulut sağlayıcısının metadata servisi böylece erişilebilir oluyordu. Ders: Uygulama sunucunu doğrudan internete açma, kullanmıyorsan WebSocket upgrade isteklerini önündeki ters vekil sunucuda kapat, sunucunun iç ağa çıkışını kısıtla.

4. Önbellek zehirleme ve XSS

Önünde bir CDN varsa, normal HTML isteği ile RSC verisi isteği karışabiliyordu. Sona bir sorgu parametresi eklenmiş RSC isteği HTML sanılıp önbelleğe yazılıyor, sonraki ziyaretçiler sayfa yerine anlamsız veri görüyordu. XSS tarafında ise beforeInteractive stratejili bir <Script> etiketine kullanıcıdan gelen bir değer (ör. URL parametresi) verildiğinde, değer düzgün kaçışlanmadığı için sayfaya başka bir script enjekte edilebiliyordu. Ders: Kullanıcı girdisini script etiketlerine hiç koyma.

Sonra ne oldu?

Bu yoğunluk Next.js ekibini süreç değiştirmeye itti. Temmuz’da ekip, büyük dil modelleriyle yapılan güvenlik araştırmalarının açık sayısını hızla artırdığını belirterek aylık, önceden duyurulan güvenlik sürümlerine geçtiğini açıkladı; ilki 21 Temmuz’da çıktı. Acil durumlar için ara sürümler de sürüyor: 25 Ağustos’ta AVIF görsel işleme ve Windows sunucularla ilgili iki kritik uzaktan kod çalıştırma açığı 15.5.24 ve 16.3.3 ile kapatıldı. 14 Ekim için de iki kritik, bir yüksek dereceli açığı kapatacak yeni bir güncelleme duyuruldu. Yani Next.js kullanıyorsan güncellemeyi ayda bir yapılan bir rutin olarak planlamak artık şart.

Düşün

  • Uygulamanda bir sayfayı koruyan tek şey middleware/proxy mi, yoksa veriyi getiren kod da oturumu kontrol ediyor mu?
  • Next.js sunucun, iç ağdaki hangi servislere ulaşabiliyor? Ulaşması gerekiyor mu?

Videoyu izle

Tıklayınca video YouTube'dan yüklenir; o ana kadar bu sayfa YouTube'a hiçbir istek göndermez.
Kaynaklar (10, İngilizce)

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.

Konu: Web3 dkVideo: Syntax

Remotion: Videoyu React ile kodlamak, artık ajana yazdırmak

Remotion, videoyu bir React bileşeni olarak yazmanı sağlayan kütüphane. Ajanlar için hazır beceriler çıkınca günlük indirme sayısı birkaç ayda kabaca altıya katlandı. Syntax'ta yaratıcısı Jonny Burger, bunun nasıl çalıştığını ve tarayıcının video tarafında neyin değiştiğini anlattı.

Konu: Web3 dkVideo: Syntax

Yapay zekâ iyi tasarım yapabilir mi? DESIGN.md ve Open Design

Yapay zekâyla yapılan siteler birbirine benziyor. Syntax'ta Wes Bos ve Scott Tolinski bunun nedenini ve yapay zekânın tasarımda nerede işe yaradığını konuştu. Aynı hafta iki araç öne çıktı: Google'ın tasarım sistemini ajana anlatan DESIGN.md dosyası ve açık kaynak Open Design.